虽然没有任何迁移,但核心数据迁移速度很慢

Question

我创建了一个新模型并重命名了一个实体的2个字段.此实体从未在之前的应用程序版本中使用过,因此我没有将其映射到数据库中新的更新实体.因此,映射不会映射任何新内容,但迁移速度非常慢(主表中大约50行为3秒).我想知道核心数据是创建新数据库还是删除旧数据库,并重新插入所有数据.这是迁移日志文件:http://cl.ly/3H1v252R1p1c

PS.如果NSInferMappingModelAutomaticallyOption是,那是否意味着我可能会遇到数据丢失,因为映射是由核心数据即兴创作的？

谢谢

Answer 1

您能向我们展示您的数据库架构吗？我的猜测是您在其中广泛使用了对象继承。

Core Data 通过为父实体创建单个表并添加列以联合子实体使用的所有字段来实现 SQL 存储中的继承。因此，您可能认为您只重命名了一个实体上的两个字段，但核心数据必须将更改应用于从该实体继承或具有该实体的共同祖先的每个对象。

在您的特定架构中，您似乎有一个实体 Item，其中至少有 Genre、AudioTrack、Studio、Director、Store、Movie、Condition、Region、Owner、AspectRatio、Year、MyRating、Episode、Edition、Format、Producer、 Writer、AudienceRating、SeenIt 和 Movie 下降。当我通过眼睛阅读你的日志而不是自动分析它时，可能还有其他人。因此，Core Data 创建了一个名为 Item 的表，其中存储了每个实体的每个实例。每当这些实体（或我可能没有找到的其他实体）中的任何一个发生更改时，核心数据都必须更新每个实体的所有实例的记录。

这就是为什么你会看到：

CREATE TABLE ZITEM ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, 
ZUNIQUEID INTEGER, ZCOLLECTIONSTATUS INTEGER, ZHASCOVER INTEGER, ZINDEX INTEGER, 
ZPLOTNOTE INTEGER, ZUSERVALUES INTEGER, ZPURCHASEDATEDAY INTEGER, 
ZPURCHASEDATEMONTH INTEGER, ZPURCHASEDATEYEAR INTEGER, ZRELEASEDATEDAY INTEGER, 
ZRELEASEDATEMONTH INTEGER, ZRUNTIME INTEGER, ZVIEWINGDATEDAY INTEGER, 
ZVIEWINGDATEMONTH INTEGER, ZVIEWINGDATEYEAR INTEGER, ZAUDIENCERATING INTEGER, 
ZCONDITION INTEGER, ZEDITION INTEGER, ZFORMAT INTEGER, ZLOANER INTEGER, 
ZLOCATION INTEGER, ZMYRATING INTEGER, ZOWNER INTEGER, ZSEARCH INTEGER, 
ZSEENIT INTEGER, ZSEENWHERE INTEGER, ZSERIES INTEGER, ZSTORAGEDEVICE INTEGER, 
ZSTORE INTEGER, ZYEAR INTEGER, ZRANK INTEGER, ZTYPEID INTEGER, 
ZCOLLECTIBLE INTEGER, Z3_COLLECTIBLE INTEGER, ZBIN INTEGER, ZSORTORDER INTEGER, 
ZSECTION VARCHAR, ZCLZID VARCHAR, ZCONNECTHASH VARCHAR, ZSORTTITLE VARCHAR, 
ZTITLE VARCHAR, ZACTORS VARCHAR, ZCLZMEDIAID VARCHAR, ZCURRENTVALUE VARCHAR, 
ZIMDBNUMBER VARCHAR, ZIMDBRATING VARCHAR, ZLOANDATE VARCHAR, ZLOANDUEDATE VARCHAR, 
ZPURCHASEPRICE VARCHAR, ZSTORAGESLOT VARCHAR, ZTITLEEXTENSION VARCHAR, 
ZUPC VARCHAR, ZTHEDESCRIPTION VARCHAR, ZURL VARCHAR, ZDISPLAYNAME VARCHAR, 
ZSORTNAME VARCHAR ) 

该表包含 Item 所有后代的所有字段的并集。这也是为什么例如 AudienceRatings 的获取执行为：

SELECT t0.Z_ENT, t0.Z_PK, t0.Z_OPT, t0.ZSECTION ... FROM ZITEM t0 WHERE  t0.Z_ENT = ?

所以：

• Core Data 正在更新超过 50 行；
• 如果你想避免这种情况，你需要避免继承；
• 您可以使用“有一个”关系来避免“是一个”关系，但核心数据的双向性质常常使这种情况变得很痛苦（如果 30 个对象与 Item 有连接，则 Item 必须与其他对象有 30 个连接）；
• 如果 Item 只是像统一时间戳这样琐碎的东西，通常只需向每个实体添加时间戳属性并让每个实体调用一段公共代码来建立它通常会更容易。