Last week was a very busy week. For those of you who were not aware, WWDC was going on. Unfortunately, I was unable to attend the conference in person, but Apple provided live-streams of several talks and made the videos available the following day. During WWDC Apple announced iOS 9, OS 10.11, and WatchOS 2. As if that wasn’t enough, Apple also announced Swift 2.0. With the release of new OS versions comes new and updated APIs.
So is anything new in Core Data? Yes there is!
New for NSManagedObject
hasPersistentChangedValues
A new property has been added, hasPersistentChangedValues. hasPersistentChangedValues returns a Bool letting us know if the object has been modified. In previous iterations, this was handled by Core Data and it was essentially a flag that was set any time an object was touched. That could lead to false positives.
objectIDsForRelationsipNamed
This new method allows you to create an Array of the object IDs of the relationship you are working with. This will let you access those relationship objects quicker and more efficiently.
New for NSManagedObjectContext
refreshAllObjects
This 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.
mergeChangesFromRemoteContextSave
If you use multiple coordinators for your persistent store, this method can take data from one coordinator and merge it to another coordinator.
shouldDeleteInaccessibleFaults
There are times when data from a relationship has been deleted from the data store. This prevents Core Data from fulfilling a fault when a related object is retrieved. By default, this will be set to true. Any fault that can’t be retrieved will be marked as deleted and the attributes for that fault will be nil.
New for NSPersistentStoreCoordinator
destroyPersistentStoreAtURL
replacePersistentStoreAtURL
Apple does not recommend that developers work directly with the persistent stores. However, some developers will perform actions on the database. These actions can have some adverse side effects like crashes and bugs. Now there is a way to delete the persistent store or replace it through the Core Data API. All the details associated with these tasks are taken care of for you.
Unique Constraints
Creating duplicate data is quick and easy, but cleaning it up can take time. Apple has now added a method to identify unique constraints for the Entities to prevent duplicate data from being entered. It is easy to set up and use too. Within the Data Model Inspector you add all the constraints separated by a comma. In the example below I have added name and courseID as unique constraints. There are some best practices to remember when setting up unique constraints. A unique constraint should be an attribute that does not change. Be aware that your sub-entities will extend the constraints.
NSBatchDeleteRequest
NSBatchDeleteResult
Last year Apple gave us the ability to update the data store using NSBatchUpdateRequest. This year they give us the ability to delete objects using a NSBatchDeleteRequest. This is a much faster process now because the delete is happening directly on the data store. The objects do not have to be loaded into memory in order to delete them. NSBatchDeleteResult provides useful information about the batch delete, such as if it was successful, how many objects were deleted, and what the object IDs were for the deleted items. For more info on how to use NSBatchDeleteRequest, see How to Use NSBatchDeleteRequest in iOS9.
There are a couple downsides to using NSBatchDeleteRequest. The data validation policies are not all enforced and any changes made to the store are not reflected in the content.
Modernization
Model Caching
Upgrading your data model requires a copy of the old model to be available. This can be cumbersome if you have several iterations of your data model. In iOS 9, Apple has introduced Model Caching. If the model is not available, then Core Data will save a copy of the current model to the data store. The lightweight migration will fetch the model from the store and update the existing stores. This only works on SQLite stores and lightweight migrations.
Subclasses
When generating subclasses you will now get two files. The standard {entity}.swift file is still created, but the properties are not stored there. This is where you will add your methods that provide additional functionality. You will now get another file, {entity}+CoreDataProperties.swift. This file will contain all of your properties for your object. If you modify your model, then you will update the properties in this new file.
Additional Resources
How to Use NSBatchDeleteRequest in iOS 9