NSMigrationManager.migrateStore with NSPersistentHistoryTrackingKey

Question

kaunteya OP

Created Feb ’25

Replies 6

Boosts 0

Participants 2

I am implementing a custom migration, and facing an issue while implementing a WAL checkpointing.

Here is the code for WAL checkpointing

func forceWALCheckpointingForStore(at storeURL: URL, model: NSManagedObjectModel) throws {
	let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: model)

	let options = [NSSQLitePragmasOption: ["journal_mode": "DELETE"]]
	let store = try persistentStoreCoordinator.addPersistentStore(type: .sqlite, at: storeURL, options: options)
	try persistentStoreCoordinator.remove(store)
}

When the coordinator tries to add the store I am getting the following error

fault: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store

My questions are

Is it really necessary to force WAL checkpointing before migration? I am expecting NSMigrationManager to handle it internally. I am assuming this because the migrateStore function asks for the sourceType where I am passing StoreType.sqlite
If checkpointing is required, then how do I address the original issue

Note:

Since my app supports macOS 13, I am not able to use the newly introduced Staged migrations.
There is similar question on Stackoverflow that remains unanswered. https://stackoverflow.com/q/69131577/1311902

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’25

I don't think you need to explicitly checkpoint the store. The Core Data migration process should handle that for you – If it doesn't, I'd see that a framework bug.

Regarding the error, did you try to set up options in the following way:

let options = [
	NSSQLitePragmasOption: ["journal_mode": "DELETE"],
	NSPersistentHistoryTrackingKey: true as NSNumber
]

Alternatively, you can use NSPersistentContainer to do the same thing:

let container = NSPersistentContainer(name: "<your container name>")
let storeURL = ...
let storeDescription = NSPersistentStoreDescription(url: storeURL)

// Turn off lightweight migration options if you would prevent auto migration.
// Core Data will then return error if the model version is incompatibile.
//
storeDescription.shouldMigrateStoreAutomatically = false
storeDescription.shouldInferMappingModelAutomatically = false
storeDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)

container.persistentStoreDescriptions = [storeDescription]
container.loadPersistentStores { (storeDescription, error) in
    ...
}

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0

Answer 2

kaunteya OP

Feb ’25

How can I confirm this behavior when migrating using NSMigrationManager?

I don't think you need to explicitly checkpoint the store. The Core Data migration process should handle that for you – If it doesn't, I'd see that a framework bug

When I enable com.apple.CoreData.MigrationDebug the lightweight migration logs the WAL checkpointing, however, when using NSMigrationManager no such log appears. Untitled Large.jpeg When I tried inserting 1000 objects, all of them get inserted into the sqlite file. Nothing gets inserted in WAL file. Is the behavior different for NSPersistentCloudKitContainer?

Regarding the error, did you try to set up options in the following way:

Yes, this works. However, if the NSMigrationManager handles this then should be avoided, right?

0

Answer 3

DTS Engineer OP

Apple

Feb ’25

The code path of lightweight migration, which does migration in place, is different from the one of running NSMigrationManager, and so I am not too surprised that the logs are different. If you can provide the logs generated by running NSMigrationManager for me to compare, I will be able to confirm. I'll be very surprised if NSMigrationManager doesn't checkpoint the data though.

I don't see any way that can force Core Data to write to the -wal file. I think if you set up a Core Data stack with multiple persistent store coordinators and write a bigger data set simultaneously, you will more likely see data being witten to the -wal file. I don't expect the behavior being different for NSPersistentCloudKitContainer.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0

Answer 4

kaunteya OP

Feb ’25

Screenshot 2025-03-01 at 10.36.48 AM.png These are the logs when migration happens from NSMigrationManager

0

Answer 5

kaunteya OP

Mar ’25

@DTS Engineer were you able to check the logs shared above?

0

Answer 6

DTS Engineer OP

Apple

Mar ’25

I haven't... The new log doesn't unveil the activities in the migration process. To give a definitive answer, I'll need to look into the framework code, which I currently don't have enough bandwidth to do.

Probably an easier approach, you might be able to test the behavior by generating a store with some data in the -wal file using multiple persistent store coordinators and a larger dataset. If you have a chance to do that, I'll be super curious on your conclusion.

I see checkpointing an internal thing in Core Data, and so would be surprised if NSMigrationManager doesn't handle that.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0