Post

Replies

Boosts

Views

Activity

Reply to SwiftData custom migration crash
@ddijitall As I said above I also tried to create a separate test project where the same issue can be replicated, so it is definitely a SwiftData/Core Data with iCloud issue. In my case, I'm trying to make things as easy as possible, to be able to perform a lightweight migration. If I'm not wrong, adding new properties or removing some can be considered lightweight, right?
Jul ’24
Reply to SwiftData custom migration crash
The scenario I'm using to answer your questions is starting from the App Store version of my app and launching the project from Xcode, containing the new schema version and the migration code. If you enable only your local configuration in your model container does both your willMigrate and didMigrate logic in your custom migration stage execute and does your schema version update? No, I tried launching with only local container enabled and the version is still 1.0. If instead you enable only your cloud configuration, what happens? If this route hits your willMigrate but crashes before it hits didMigrate then the migration is not happening. In this case, the migration is not even reached because the fails happens during the creation of the ModelContainer. The error is this: UserInfo={NSLocalizedFailureReason=Unable to find a configuration named 'default' in the specified managed object model.} with userInfo { NSLocalizedFailureReason = "Unable to find a configuration named 'default' in the specified managed object model."; } Setting up both configurations in series and discarding the local configuration might be masking this issue by preventing a crash while at the same time failing to migrate. Could this be why your schema version is not changing? This could be the case, I have to investigate further. The big issue here is that migration is a very important part of database management and the fact that is crashing while everything seems to be performed in the right way is a major problem.
Jul ’24
Reply to SwiftData custom migration crash
@DTS Engineer I will give it a try with the latest beta of iOS 18 and Xcode 16. In the meantime, what is the suggested workaround? Because what I'm doing is this: extension ModelContainer { static var myContainer: ModelContainer { print("ModelContainer | myContainer called") let schema = Schema([ CDShift.self ]) let cloudConfiguration = ModelConfiguration( isStoredInMemoryOnly: Ecosystem.current.isPreview, groupContainer: .identifier(Ecosystem.current.appGroupIdentifier), cloudKitDatabase: .automatic ) let localConfiguration = ModelConfiguration( nil, schema: schema, isStoredInMemoryOnly: Ecosystem.current.isPreview, groupContainer: .identifier(Ecosystem.current.appGroupIdentifier), cloudKitDatabase: .none ) do { let container: ModelContainer if let cloudContainer = try? ModelContainer( for: schema, migrationPlan: MigrationPlan.self, configurations: cloudConfiguration) { AMLogger.verbose("Cloud container created, CloudKit is enabled!") container = cloudContainer } else { AMLogger.verbose("Cloud container failed to create, we will now create a local container and then again a cloud container.") _ = try ModelContainer( for: schema, migrationPlan: MigrationPlan.self, configurations: localConfiguration ) container = try ModelContainer( for: schema, migrationPlan: MigrationPlan.self, configurations: cloudConfiguration ) AMLogger.verbose("Cloud container created after local one.") } AMLogger.verbose("SwiftData path: \(container.configurations.first!.url.path)") return container } catch (let error) { fatalError("Could not create ModelContainer: \(error)") } } } I try to create a cloud container and, if it fails, I create a local one to perform the migration, then try again to create the cloud one. The issue is that it seems that the version of the schema keeps staying on "1.0.0".
Jul ’24