理解版本
版本控制有两个截然不同的观点：作为开发人员的视角，以及Core Data的观点。这写可能不总是相同的。
Figure 1-1 Recipes models “Version 1.0”
Figure 1-2 Recipes model “Version 1.1”
Figure 1-3 Recipes model “Version 2.0”
作为开发人员，你的版本通常是由标识符（字符串或数组）表示，如“9A218”，“2.0.7”或“版本1.1”。要支持此图，托管对象模型具有一组标识符，对于单个模型，提供单个字符串（属性本身是一个集合，以便如果模型合并，则可以保留所有的标识符）。标识符应如何解释取决于开发人员，无论是代表应用程序的版本号，在之前提交的版本，还是还是在停止工作之前的最后一次提交。
另一方面，Core Data将这些标识符简单的称为“提示”。要了解为什么，请记住，持久储存的格式取决于用于创建它的模型，并且要打开持久储存，必须具有与用于创建持久储存的模型兼容的模型。试想下如果更改了模型而不更改标识符会发生什么-比如，将标识符不变，但是删除了一个实体，并且添加了另外两个实体。对于Core Data来说，模式的变化（schema change）是非常重要的，而标识符有没有改变的事实无关紧要。
对于Core Data来说（从Core Data视角来说），版本控制只对影响持久性的模型的功能感兴趣。这意味着对于两个型号要兼容：
对于每个实体（entity），以下属性必须相等：name，parent，isAbstract，properties。
className，userinfo和validation predicates不进行比较。对于每个实体中（entity）的每个属性（property），以下属性必须相等：name，isOptional，isTransient，isReadOnly，for attributes attribute Type，for relationships destinationEntity，minCount，maxCount，deleteRule，inverseRelationship。
userinfo和validationpredicates不进行比较。
请注意：Core Data忽略您设置的任何标识符。在上述示例中，Core Data将1.0版本（图1-1）和1.1（图1-2）视为兼容的。
Core Data不是通过模型的所有相关部分枚举，而是创建了一个32字节的哈希摘要，该数据比较了相同的组件和versionHash。这些哈希值包含在储存的元数据中，以便Core Data可以快速确定储存格式是否与可能用于尝试打开储存的托管多想模型匹配。（当你尝试使用给定模型打开储存时，Core Data将储存中的每个实体的版本散列与模型中的实体的版本哈希进行比较，如果全部相同，则打开储存）通常没有理由对哈希的价值感兴趣。
然而，可能有一些情况下，你认为不一样的两个版本，Core Data通常会将他们当做相同的版本对待。例如，你可能更改用于表示实体类的名称，或者更细微的，使模型保持不变，单更改了诸如BLOB的属性的内部格式。这与Core Data无关，但是对于数据的完整性至关重要。为了支持这一点，Core Data允许开发人员为实体（entity）或者属性设置散列修饰符。（详情关于：NSEntityDescription 和NSpropertyDescription）
在上面的例子中，如果想强制Core Data认识到你的模型版本1.0（图1-1）和版本1.1（图1-2）是不同的，那么可以为第二个模型中的的实体更改Core Data创建的版本散列（version hash）。
