{"id":40349,"date":"2023-08-15T15:36:18","date_gmt":"2023-08-15T19:36:18","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=40349"},"modified":"2023-08-15T16:08:52","modified_gmt":"2023-08-15T20:08:52","slug":"turning-off-core-data-persistent-history-tracking","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/08\/15\/turning-off-core-data-persistent-history-tracking\/","title":{"rendered":"Turning Off Core Data Persistent History Tracking"},"content":{"rendered":"

It’s not documented, but Core Data doesn’t like you to turn off persistent history tracking once it’s been enabled for a store. If you set NSPersistentHistoryTrackingKey<\/code> to false<\/code> after it had been set to true<\/code>, opening the store will seem to succeed, but it will log<\/a> an<\/a> error<\/a> like:<\/p>\n

Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store at<\/pre>\n
No error is reported to your code, although you can check whether store.isReadOnly<\/code> matches what you passed for NSReadOnlyPersistentStoreOption<\/code>. If you fail to notice this, your app is likely to crash at some point. For example, the NSPersistentStoreCoordinator.setMetadata(_:for:)<\/code> method will raise an NSInvalidArgumentException<\/code>, which cannot be caught in Swift.<\/p>\n
This makes sense in that, if you could turn off history tracking and later turn it back on, the history would be there but would have a gap, which could lead to bugs. In my case, though, I had only turned on history tracking to track down a bug—which ended up not being an unexpected writer but rather a bug in Core Data’s uniqueness constraint conflict resolution. I no longer needed history tracking for that store and wanted to avoid the associated performance cost.<\/p>\n
It turns out that you can<\/em> turn off history tracking if you first delete the history. So, I can open the store with NSPersistentHistoryTrackingKey<\/code> set to true<\/code>, then execute this request:<\/p>\n
let request = NSPersistentHistoryChangeRequest.deleteHistory(before: .distantFuture)<\/pre>\n
Internally, this seems to only do a batch delete on the ACHANGE<\/code> and ATRANSACTION<\/code> tables. It does not actually clear out the interned strings in ATRANSACTIONSTRING<\/code> or remove the history tracking tables themselves. But the bulk of the data is gone, and Core Data will let me re-open the store with NSPersistentHistoryTrackingKey<\/code> set to false<\/code>.<\/p>\n
Going forward, I will add a key to the store’s metadata to record whether it was last opened using NSPersistentHistoryTrackingKey<\/code>. When loading the store, if the key is true<\/code>, I know to remove the history and can avoid logging the error. If it’s false<\/code>, I know that the store can be safely opened without adding the history tracking tables.<\/p>\n\n
Previously:<\/p>\n