Core Data in El Capitan
There are again no Core Data release notes this year, but there is WWDC 2015 Session 220 (video, PDF):
Previously you may have used
-hasChanges, this was a rather basic dirty flag, if you touch the object, we would mark it dirty. But with-hasPersistentChangedValueswe’ll ensure that the properties on the object are different than what’s in the persistent store ensuring you don’t have any false positives.Also new on
NSManagedObjectis-objectIDsForRelationsipNamed:for relationship named. This is ideal for working with large relationships mainly because we won’t materialize the entire relationship in memory rather we’ll return to typed array of object IDs to you. This allows you to go through these object IDs and work with your objects in smaller sizes.[…]
Well Core Data has you covered this year, simply tell us which attributes should be unique across any entity and we’ll make sure all instances of that entity keep that unique attribute, be it email addresses, part numbers, UPC, you name it, we’ll make sure it is unique across all instances.
[…]
NSBatchDeleteRequestworks likeNSBatchUpdateRequestin that it acts directly in the persistent store without loading any objects into memory.[…]
Whenever you have a store that’s created or migrated or just opened on the new iOS from an older version the managed object model used to create it is cached into the store and it is used by lightweight migrations when they fail to find appropriate source model as sort of a last-ditch effort.
And there you have it! That’s all you need to get unique constraints working in Core Data. In my demo project, I’ve used a
NSFetchedResultsControllerto show where unique constraints will not work well. If you’re displaying data using a fetched results controller, you’ll still see entities with non-unique properties, since conflict resolution only happens when saving our managed object context, and fetched results controllers work with in-memory objects.
refreshAllObjectsThis refreshes all the objects in the context while preserving the unsaved changes. The references will remain valid and it will break any retain cycles that may have been inadvertently created.
Florian Kugler and Daniel Eggert:
When using multiple managed object contexts concurrently, you also have to handle race conditions when deleting objects. iOS 9 and OS X 10.11 have a convenient solution for this problem in the form of the context’s
shouldDeleteInaccessibleFaultsproperty. However, this convenience comes with tradeoffs. Alternatively you can implement robust deletion using a two-step deletion process.
Despite all the talk about how Core Data is not a database, it seems to be continually growing database-type features. And that’s a good thing. Why not use the power of the underlying SQLite engine?
