It’s pretty easy to define a #SwiftLang OptionSet & then store it in a #CoreData Int using a custom getter and setter.
Testing suggests it’s possible to fetch based on specific option, i.e. NSPredicate like:
…which works great till app crashes during iCloud sync with something like: "Exception was caught during Core Data change processing. [snip] Can't do bit operators on non-numbers with userInfo (null)” Thoughts? #iOSDev => /toot/113354211641914954 More informations about this toot => /profile/109316476889979346 More toots from babbage@iosdev.space # Descendants ### Written by Duncan Babbage on 2024-10-23 at 01:50 I know with Core Data sync operations sometimes properties that otherwise always have a value (e.g., there’s a default set) are null, and my best guess is the bitwise operator chokes on that during change processing? For now, will prob stick with OptionSet but just restructuring to not use a bitwise operator, by focussing on specific cases I need, e.g.,
format: “options == %i OR options == %i",
options.rawValue,
MyOptions.all.rawValue
)`
=> More informations about this toot | More toots from babbage@iosdev.space
The biggest challenge with this is I’ve seen the app crash three or four times in testing this in large sync operations but it’s very infrequent (thousands of transactions fine then a crash), and so impossible to reliably test at this stage. The only thing I’ve proven to myself is it can happen both when the app is in the foreground and background, so it’s not dependent on whether a particular SwiftUI view that is responding to the fetch is visible on screen. Which is nearly no lead at all.
=> More informations about this toot | More toots from babbage@iosdev.space This content has been proxied by September (3851b).Proxy Information
text/gemini