I'm at a point with swift where creating the GUI is going smoothly. I'd like to start incorporating real data.
When I originally posted this, I didn't know about Core Data - usually that has a negative connotation. Is Core Data the most used model management middleware?
In looking at Realm, it seems to have a few Objective-C left overs. As a new user, I'm assuming the Next "NS" and Objective-C designations in code mean that it needs to migrate.
It’s hard to answer this without more information about your requirements. For example, if you are storing just a few values then putting them in a property list (or JSON) via the Codable protocol is both appropriate and really easy. On the other hand, if you’re storing hundreds of thousands of records then the complexity of Core Data is definitely justified.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
Thank you for your answer - generally there are about 50 - 75 models with various relationships. I'd like to be able to store maybe 100-1000 objects per model in the prototype - but yes, the final product would be in the hundreds of thousands, it's for semiconductor design. So do most larger apps use Core Data in both the production version and the prototype?
So do most larger apps use Core Data in both the production version
and the prototype?
The best advice I’ve heard on that front is to make sure that you don’t let persistence infrastructure artefacts (for example, NSManagedObject) escape from your model layer. That way you can change model layers without rewriting everything (it also helps isolate you from any potential weirdness in the persistence infrastructure).
the final product would be in the hundreds of thousands
CoreData can do that but you have to be really careful you don’t trip over some pathological behaviour. But the same would be true of any persistence infrastructure once you start dealing with that many objects. Accidentally deserialising 100,000 objects is likely to be slow no matter how efficient your model infrastructure is.
What’s your expected mutability pattern? Is this data going to be immutable? Or infrequently mutated? Or mutated a lot? And are the mutations scattered about randomly? Or with some obvious pattern, like mutating lots of related items at once?
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
Sorry for delay in responding - had to get up to speed on some of your terms and types. Currently going through Ray W's book on Core Data.
By escaping model layer - I'm taking that as making sure that NSManagedObject is contained within a model service API. I think that's great advice.
In general, I'm trying to create a mutability pattern in the system that would allow for Reactive streams. It's very similar to how chip architecture languages work - Verilog and VHDL. While I find Reactive streams cumbersome to implement, I think it's a good long term goal. The objects were talking about would be value based and immutable.
In my basic readings, I haven't bridged Core Data to an external database yet, only the local. Versioning (not migration) is something I'd like to explore. So by "Database" in my original question, should have really been 'cloud' or 'central server'.