{"id":32029,"date":"2021-03-31T10:08:13","date_gmt":"2021-03-31T14:08:13","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=32029"},"modified":"2021-03-31T10:17:58","modified_gmt":"2021-03-31T14:17:58","slug":"replacing-vs-migrating-core-data-stores","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/03\/31\/replacing-vs-migrating-core-data-stores\/","title":{"rendered":"Replacing vs. Migrating Core Data Stores"},"content":{"rendered":"

Apple Frameworks Engineer<\/a>:<\/p>\n

Additionally you should almost never use NSPersistentStoreCoordinator<\/code>’s migratePersistentStore<\/code> method but instead use the newer replacePersistentStoreAtURL<\/code>. (you can replace emptiness to make a copy). The former loads the store into memory so you can do fairly radical things like write it out as a different store type. It pre-dates iOS. The latter will perform an APFS clone where possible.<\/p><\/blockquote>\n\n

Tom Harrington<\/a>:<\/p>\n

\n

[This] method is almost totally undocumented, so you’re on your own working out how to use it. The dev forums post mentioned above is from summer 2020. The replacePersistentStore(...)<\/code> method was introduced five years earlier in iOS 9, but the forum post was the first time most of the information appeared.<\/p>\n

[This] is the first suggestion I’ve seen that migratePersistentStore(...)<\/code> might not be a good idea anymore. It’s not deprecated and I haven’t seen any previous source recommending against its use.<\/p>\n<\/blockquote>\n

There are some comments in the header.<\/p>\n

Incidentally you won’t find this if you’re using Swift and ⌘-click on the function name. You need to find the Objective-C header. One way to do this in Xcode is to press ⌘-shift-O and start typing the class name.<\/p>\n

[…]<\/p>\n

Its declaration says it can throw. I tried intentionally causing some errors but it never threw. For example, what if sourceURL<\/code> points to a nonexistent file? That seems like it would throw, especially since the function doesn’t return anything to indicate success or failure. It doesn’t throw, although there’s a console message reading Restore error: invalidSource(\"Source URL must exist\")<\/code>.<\/p>\n<\/blockquote>\n\n

He’s figured out a lot, though other important details like the APFS support remain a mystery.<\/p>\n\n

Tom Harrington<\/a>:<\/p>\n

The demo app I’ve been using is now on GitHub. You can take a look here<\/a>. Or go directly to the diff of replacing migrate<\/code> with replace<\/code> here<\/a>.<\/p>\n

[…]<\/p>\n

The backup process is simpler than it used to be, because replace<\/code> doesn’t have the same side-effect that migrate<\/code> did of unloading the persistent store.<\/p>\n

[…]<\/p>\n

Even though the migrate<\/code> and replace<\/code> methods seem pretty similar, the semantics are slightly different when the destination is a currently-loaded store. My new restore code reflects that.<\/p><\/blockquote>\n\n

Previously:<\/p>\n