添加一个新的核心数据模型版本，以我的应用程序后，我进行了一个轻量级的迁移，显然是成功的。 迁移的文件加载细，但在经由特定关系，应用程序崩溃与访问的属性的第一次尝试NSRangeException: '*** -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds [0 .. 35]' 。 这种关系能正常工作之前迁移。 我从这里其他职位知道4294967295真的是-1 ，但我可以在我的应用程序36项标识的唯一的事情/数据是，有数据模型，共36单位（供参考，这是取有58个关系在表格中的项目）。
问题：
我的问题是：根据我得到的错误，我已经做了以下的故障排除，有没有一种模式的变化，可以通过轻量级迁移，但腐败沿途的数据，导致指出例外？ 我要去尝试打破迁移成小块过几个版本要么隔离或回避的问题，但它会很高兴能够把重点放在可能是有过错的具体架构更改。
失败：
失败与“MyObject来”下面的代码出现：
[[self object2] text];
该Object2的关系是一对一，非可选两种方式既不前进也不是反向关系数据模型之间的变化。 该text属性可能是不相关的，因为当发生错误， awakeFromFetch未达到Object2的。 如果我分配[self object2]之前上述声明的变量，所述分配成功和报告data: <fault> 。
数据库：
看着sqlite3的数据库中，我注意到以下：
- 前向和反向关系的指数值似乎是在每个表是正确的。
- 该Object2的表具有用于反比关系两列，而不是一个在迁移之前（
ZMYOBJECT如之前和附加Z2_MYOBJECT ，里面是空的所有行）。 不加入其他关系来解释此列。 - 在
Z_PRIMARYKEY表，所有条目迁移后出现-1的Z_MAX ，而在迁移之前他们表现出零对空表和填充表格的最大行数。 手动更新Z_MAX以正确的价值观并没有不同之处帮助。 所有Z_SUPER值是正确的。
我成立了一个映射模型来看看是否有什么歪看着与自动映射，但一切似乎都很正常。
总体架构更改 ：
在数据模型中的源代码版本，有共有十四实体，其中只有四个已经填充了数据（应用程序仍处于开发阶段）。 七是顶级实体，七三个顶级实体的子实体。
在数据模型的目标版本中，加入22单位，一些顶层和一些子实体，与数十家的关系，包括一些添加到现有的实体。
一些属性和关系，从现有的实体被拆除，并加入其他人。 没有任何数据类型或关系设置被修改，没有属性或关系进行了重新命名，并且不需要特殊的映射。
更新（12年2月25日）：当我开始一个新的中间模型的工作，我记得我改变了类（representedClassName）的数量从NSManagedObject到NSManagedObject子类的实体，但还没有生成的类文件。 我没有怀疑会导致一个问题，事实上，创建所有的类文件并没有不同之处帮助。 我只是想指出，作为模型之间的另一个变化。
结论：
这是胡乱猜测，但如果36单位数是不是巧合，似乎在“为MyObject”试图在“对象2”故障不会对表有一个有效的参考，并试图加载表号-1 ，导致异常。 事实上，一个简单的任务[self object2]是成功的，但是，不符合这一结论嘲弄。
有任何想法吗？
通过几个增量迁移工作，我能够确定是什么原因造成的问题，以及解决方案。
问题：
一个与数据的现有实体在当前的模型没有子实体。 如果我创建一个新的模型，只是增加了一个子实体，不含属性或关系，并使得没有其他变化，NSRangeException，Z_MAX观察和反比关系的加倍在我的问题都发生指出。
解决方案：
观察按照以上的情况下的“成功”轻质迁移失败后，我创建映射模型。 由于唯一的变化是一个额外的实体，所有，但实体映射的一个是简单的。 问题是跟单加实体做什么。
默认情况下，没有属性或它自己的关系添加实体展示了所有家长的性能属性和关系映射。 所有映射了默认为空值的表达式，这我以为意味着它只是在迁移过程中跳过它们。 事实并非如此，显然。 通过删除所有的属性和关系的映射的实体映射内，然后关闭推断映射，迁移成功进行。
我还是要解决所有剩余的实体，将尝试做其他散装的，具有完整的所有计划属性和关系这种做法。
Your posts were helpful when I encountered this problem. Thank you. [Have you reported the bug yet?]
Here are some more experimental results but, alas, not a great solution.
My schema change similarly added an entity subtype that has no additional attributes or relationships. The error message is the same as yours except the bounds are [0 .. 19]. That does correspond to 20 entity types, validating your hypothesis. Like your situation, the error happened when attempting to access an entity property after migration completed.
Adding a dummy attribute and a dummy self-relationship to the new entity type didn't avoid the post-migration crash. (However, I didn't test with that new entity type as the only schema change since I previously pushed that schema change to alpha testers.)
I observe the Z2_MYOBJECT column and Z_PRIMARYKEY.Z_MAX = -1 symptoms after successful migrations for other schema changes, so those may not be problematic at all. The -1 values get replaced lazily by the proper max values. The extra column might be used during migration.
In my case, the new entity's supertype has an ordered to-many relationship. In the very simple case where the entire data store contains just one object instance (an instance of that entity type with no outgoing relationship links), the schema migration succeeds. It does have the extra Z2_MYOBJECT column and Z_PRIMARYKEY.Z_MAX = -1 values and yet the resulting data store works fine when adding objects from there.
I tried creating a mapping model but was unsuccessful in getting Core Data to apply it. Turning off inferred mapping just made Core Data unable to migrate at all. Is there a trick to it? Do I have to write custom migration code to invoke a mapping model? This is Xcode 4.6.2 so the older bug is long gone.
When using git to roll the code & data model backwards or forwards to conduct an experiment, it seems to be necessary to (1) close & reopen the Xcode project and (2) do a clean build. Otherwise Xcode may crash and/or leave confounding state around.
To experimentally roll backwards, you must delete the .momd/ directory or the entire app from the target iOS simulator/device (or deploy the app via iTunes or TestFlight) since redeploying via Xcode won't remove obsolete files (like .mom and .omo data model definitions) which in turn lets the app do lightweight migrations that the actual deployed app can't do.
About the entity mapping to use for the added entity type, note that when Core Data applies a mapping model, it's copying entities from the old data store to a new one. It's not modifying the tables in place. You don't want it to "skip" properties (including inherited properties) unless you want to drop them.
However, since the schema change added an entity type, that entity has no instances to migrate so its custom mapping model rules do not matter.
Thus I wonder if something else caused your crashes to stop, like leftover experimental .mom files or custom migration code. Did your workaround hold up?
After 2 days of experimenting I decided my alpha testers would have to live without data migration this time. Fortunately this happened without production customers. But it doesn't give me confidence in Core Data.
我有相同的排序NSRangeException自动轻量级迁移后访问特定实体的任何实例时，增加一个核心数据模型版本之后。 在我的情况也是范围对应的实体在我的模型的数量。
我生成和Xcode 4.6使用（4H127）映射模型File > New > File... ，然后选择Core Data > Mapping Model 。 这导致崩溃至（d）演变成-[NSSymbolicExpression length]: unrecognized selector sent to instance...
解
在我的情况的问题是我造成初始崩溃的实体有一个名为关系size ，这是苹果中列出的保留字谓词编程指南 。 映射模型的检查发现，保留字已经为关系的价值体现资本化：
FUNCTION($manager, "destinationInstancesForEntityMappingNamed:sourceInstances:" , "PNSizeOptionToPNSizeOption", $source.SIZE)
我发现，在解决核心数据模型版本和数据迁移编程指南 ：
在自定义值表达式的保留字：如果您使用自定义值表达式，你必须逃脱保留字，如大小，第一个和最后使用＃（例如，$＃源的大小）。
不幸的是，Xcode的算法生成映射模型不承认的保留字，我不得不改变在关系映射检查员表达的关键路径$source.#size 。 这解决了这个问题。 我认为核心数据的推断映射模型轻量级迁移过程中遇到了类似的问题。
可能有这种崩溃等原因造成，因此这种解决方案可能不适用，但它可能是值得检查的属性名称在你对的中保留字列表模型谓词编程指南 。
