问题标签 [mapping-model]

我现在有大约 4 个不同版本的数据模型，除了最后一个之外，每个版本都只是使用自动轻量级迁移进行的微小更改。对于这个最新的模型，我需要在迁移过程中做一些额外的工作，所以我创建了一个自定义映射模型和一个迁移策略子类，其中包含一些在 createDestinations 和 createRelationships 中的操作。问题是，我的映射模型/自定义策略没有被调用，似乎 Core Data 正在尝试执行轻量级迁移。我需要做些什么来保持轻量级迁移，但是在有可用的映射模型时使用我的映射模型？

我有核心数据应用程序，并且一直在迁移（升级）核心数据模型。每次我创建一个新版本时，我都会为每个版本创建一个映射模型。现在我有 16 个版本，我有这样的映射模型：1to2.xcmapingmodel 2to3.xcmapingmodel 3to4.xcmapingmodel ...等。最多 16 个

这工作正常，但是当一个用户拥有版本 10 的数据文件并更新版本 16 的应用程序时会出现问题。我认为 Core Data 会自动从 10 升级到 16，但出现一个错误，显示“缺少映射模型”。为了确保映射模型正确，我将它一个一个升级到每个版本（10 到 11、11 到 12 等），它确实有效……这是我的代码。

我使用以下代码指定模型版本：

我在这里定义了 Migrate Automatic 选项：

有谁知道如何升级这个？谢谢你。

我正在尝试迁移大约 11Mb 的 iPhone/iPad sqlite 存储。它有大约三十个不同的实体，所有这些实体都非常相互关联。

在 3GS 上，这需要相当长的时间。即使是轻量级迁移也需要大约四分钟。

我想这是因为所有的关系都保存在记忆中。

阅读 Apple 迁移指南，它说对于大型数据集，一种方法是使用不同的映射模型进行多次传递。

一切都很好。但是，如果一个映射模型中的实体与另一个映射模型中的实体相关，您似乎无法执行此操作。事实上，在映射模型 xcmapingmodel 文件中，按照“can't auto generate value expression with nil mapping name”的行生成编译错误。

非常感谢任何提示。

非常感谢，

最大限度

我现在正在编写我的第一个 NSEntityMigrationPolicy，这个非常简单。它从数据库中获取一个单例，然后翻阅其他三种类型的记录，并将它们链接到单例，以获得已添加到这些类中的新关系。

现在，我在方法中的 NSEntityMigrationPolicy 的单个子类中执行此操作，该endEntityMapping:manager:error:方法一次更新所有三种类型的对象。我不确定的事情是一次完成所有这些是否安全，或者我是否真的需要实施三个单独的策略......似乎endEntityMapping在所有迁移完成后调用回调，甚至如果我在映射模型编辑器中将映射名称设置为所有三个类的“自定义策略”字段，它似乎只被调用一次。

只是想检查像这样在单个endEntityMappingimpl 中执行所有操作是否安全？似乎确实如此，但这是我想确定的事情。

提前感谢您的帮助。

我有一个使用 core-data 的可可应用程序，它现在是其托管对象模型的第 4 版。

我的托管对象模型包含抽象实体，但到目前为止，我已经设法通过创建适当的映射模型并使用 addPersistentStoreWithType:configuration:options:error 并将 NSMigratePersistentStoresAutomaticallyOption 设置为 YES 创建我的持久存储来进行迁移。

当我从模型版本 3 迁移到 4 时，这可以正常工作，这是一种涉及向多个实体添加属性的迁移。现在，当我尝试添加新模型版本（版本 5）时，对 addPersistentStoreWithType 的调用返回 nil 并且错误仍然为空。从 4 迁移到 5 涉及添加单个属性。

我正在努力调试问题并检查了以下所有内容；

1. 源数据库实际上是版本 4，persistentStoreCoordinator 的托管对象模型是版本 5。

2. 4->5 映射模型以及版本 4 和 5 的托管对象模型存在于我构建的应用程序的资源文件夹中。

3. 我尝试了各种模型升级路径。奇怪的是，我发现从早期版本 3 -> 5 升级是可行的.. 但从 4 -> 5 升级失败。

4. 我已经尝试添加自定义实体迁移策略来迁移其属性正在更改的实体......在这种情况下，我覆盖了方法 beginEntityMapping:manager:error: 。有趣的是，当迁移工作时（即当我从 3 迁移到 4 或从 3 迁移到 5 时），这个方法确实会被调用，但在失败的情况下（4 到 5 ）它不会被调用。

我几乎不知道从哪里开始。任何有助于调试此问题的想法将不胜感激。

我遇到了一些我遇到问题的 beta 测试人员的奇怪崩溃。符号化的崩溃报告表明崩溃发生在作为单例的控制器的简单分配中，在 init 调用中，但根据堆栈跟踪，看来我所拥有的代码init实际上并不是崩溃所在的位置。以下是相关代码：

这以前从未崩溃过，而且代码最近也没有任何变化。这是引发的堆栈跟踪：

关于这个神秘的崩溃是什么以及它可能来自哪里的任何想法？

---

更新 1
它似乎与核心数据和迁移有关。我能够复制它，但根本原因仍然未知。我在这个版本中有一些自动迁移，看起来虽然可以读取一些 NSManagedObjects，但其他人正在抛出这个异常，特别是在 NSManagedObjects 关系上。可能根本就没有关系PlayerController。任何核心数据专家都有一些见解？

---

更新 2
这是我找到重现它的方法
和相关代码后崩溃的调用堆栈：

为了帮助解释我做了什么来重现它，我必须稍微解释一下数据结构。我有Mix和Audio项目。混音有很多音频，音频属于很多混音。这是对 MixAudio 对象的简单关系调用以获取音频。现在，这只是在我将数据库还原到新版本后才崩溃。

我的设置中的数据库备份意味着压缩数据库以保存数据，然后在还原时解压缩。此崩溃仅在还原过程之后发生。更复杂的是，有 3 个带有映射模型的数据库版本。因为这个过程在版本控制之前对我有用，所以我觉得我的版本中的某些东西导致了这个崩溃。

所有其他数据都很好，可以访问，甚至保存。不知何故，这个单一的提取导致了问题。设置持久存储或托管对象模型时没有错误或警告。此外，可以很好地创建和访问新的 Mix 对象，只有较旧的提取（在还原之前位于数据库中）失败。

如果我没有发现错误，控制台会打印：

在崩溃线周围放置 atry/catch可以让我检查根本崩溃原因：

valueForKey但这对于一个简单的电话来说毫无意义（至少对我来说） 。4294967295 = 2^32-1 这意味着如果有帮助，索引 var 可能设置为 -1。我在这里迷路了。

---

[已解决] 更新 3
我在版本控制中是对的 :) 我重新阅读了Zarra 书中关于版本控制的部分，并且有一个重要的DOH时刻。这是我第一次拥有具有 3 个数据库版本的应用程序。我在我的应用程序中使用映射模型，我天真地假设核心数据能够使用一个模型从 1-2 映射，然后使用下一个模型映射 2-3。当我意识到我没有 1-3 映射模型时，我真的撞到了头。为了测试它，我快速添加了一个，一切都像黄油一样光滑。现在我只需要回去使用他的Progressive Data Migration样本来让我的生活更轻松，因为我继续使用更多版本的数据库。

我希望 Zarra 开车经过这里并回答一些事情……任何事情……这样我就可以给他分数了 :)

我有我的旧数据模型、我的新模型（相同但在一个实体中多了两个文本字段）和一个映射模型（只是默认生成的一个）。

当我进行自动迁移时，我得到一个崩溃和一个堆栈跟踪，看起来它进入了一个无限循环，62851 个堆栈帧，主要是 _PF_Handler_Public_GetProperty 和 NSManagedObject 上的描述，由 malloc 错误终止，我认为这是无限循环内存不足在我的设备上。

你知道什么会导致这样一个无限循环吗？我不知道从哪里开始调试。

干杯

尼克

在我的核心数据模型的新版本上添加新实体会导致使用旧版本核心数据模型的应用程序崩溃吗？

如果该实体与现有实体有关系怎么办。

我有一个数据量很大的应用程序，并且我已经使用 XCode 中的可视映射模型和 NSEntityMigrationPolicy 实现中的清理代码实现了我所有的 CoreData 迁移内容。事实证明，真实设备上的迁移非常耗时，有时需要长达五分钟才能完成。

当这种情况发生时，我真的需要向用户提供反馈，并且想要 KVO migrationProgressNSMigrationManager 上的属性。诀窍是，addPersistentStoreWithType:configuration:URL:options:error:如果它认为有必要进行迁移，它不会让您获得对 NSMigrationManager 的引用。

我发现我可以通过beginEntityMapping:manager:error:在我的自定义 NSEntityMigrationPolicy 上实现回调来获得对 NSMigrationManager 的引用，从那里开始观察。

唯一的问题是，当您beginEntityMapping接听电话时，进度似乎高达 30% 左右（此外，这 30% 通常代表在通话中花费的总时间的一半addPersistentStoreWithType左右，所以它实际上比看起来更糟糕）。

有没有其他人知道任何技巧可以用来在程序的早期获得对 NSMigrationManager 的引用，这样我就不必错过前三分之一的机会向用户提供关于为什么应用程序的反馈启动需要这么长时间吗？

提前感谢您的帮助！

我有一个广泛使用 CoreData API 的应用程序。我正在开发一个更新版本，向实体添加一些字段。由于架构更改，我的应用程序在加载时崩溃（除非我清除私有存储并重新启动）。

问题是当客户升级到新版本时，我不介意在第一次加载应用程序时对其数据运行升级程序，但我什至无法加载它，因为 CoreData 不喜欢架构更改.

有没有办法告诉CoreData“没关系..不要担心架构更改”？因为我只添加了字段，没有重命名或删除任何内容。