我遇到了使用Realm迁移块和迁移域的策略的问题。
给定一个具有许多属性的对象MyObject:
给出以下迁移块:
private class func getMigrationBlock(realmPath: String) -> RLMMigrationBlock {
return { migration, oldSchemaVersion in
if (oldSchemaVersion == RLMNotVersioned) {
NSLog("No database found when migrating.")
return
} else {
NSLog("Migrating \(realmPath) from version \(oldSchemaVersion) to \(RealmMigrationHelper.CURRENT_DATABASE_VERSION)")
}
NSLog("Upgrading MyObject from version %d to %d", oldSchemaVersion, CURRENT_DATABASE_VERSION)
if (oldSchemaVersion < 2) {
migration.enumerateObjects(MyObject.className(), block: {
oldObject, newObject in
newObject["myPropertyMk2"] = oldObject["myProperty"]
})
}
if (oldSchemaVersion < 3) {
migration.enumerateObjects(MyObject.className(), block: {
oldObject, newObject in
newObject["myPropertyMk3"] = oldObject["myPropertyMk2"]
})
}
NSLog("Migration complete.")
}
}
当我是数据库的第2版时,这工作得很好(显然没有 oldSchemaVersion&lt; 3 块),但是当我介绍版本3时,我开始遇到问题因为它无法识别 oldSchemaVersion&lt; 中的 newObject [&#34; myPropertyMk2&#34;] 2 阻止。如果我将其更改为 newObject [&#34; myPropertyMk3&#34;] ,它可以正常工作。
通过阅读RLMMigration代码,当我们使用旧的schme和新方案时,这非常有意义,但基于realm.io上的文档,我认为这没有道理。然后我原本预计它会减少计划。
我有一个想法,只需使用字典,然后最终将此字典应用于 newObject ,即可在方块内减少迁移。
对于处理此问题的领域的迁移策略有什么想法吗?它在领域网站上提到,但只是非常简短。
谢谢:)
答案 0 :(得分:1)
感谢您提出问题并报告您的问题。
通过阅读RLMMigration代码,当我们使用旧的schme和新方案时,这非常有意义,但基于realm.io上的文档,我认为这没有道理。然后我原本预计它会减少计划。
正如您从RLMMigration
中的代码中正确识别的那样,迁移不是无方案的。您提供的迁移关闭应该处理从过去的任何版本到当前版本的迁移。如果您的用户之间没有更新您的应用程序,因此跳过了一个版本,那么Realm可能无法知道您的中间架构版本,因为架构会在运行时反映出来。您通常可以自由地打破与现有旧版本的向后兼容性,但您需要注意将配置重置为已定义的状态。
对于这一点你肯定是正确的,这可以更好地记录下来。我已经创建了一张内部票据。
我有一个想法,只需使用字典,然后最终将此字典应用于newObject,即可在块内减少迁移。
对于处理此问题的领域的迁移策略有什么想法吗?它在领域网站上提到,但只是非常简短。
根据您的方案和您拥有的数据量,您可以通过字典在内存中以对象方式重新组织它,然后将其应用于您描述的newObject。当前的API做出相对较少的假设,并允许这样的方法。但它不会以这种方式对每个人都有益,例如如果您有相关对象的大型列表。