核心数据推断迁移——自动“轻量级"与手动 [英] Core Data Inferred Migration – Automatic "lightweight" vs Manual

问题描述

我已经通过一些简单的方式(删除属性、添加属性、删除索引)更新了现有 iPhone 应用的模型，并且可以使用自动轻量级迁移来迁移持久存储.

I've updated the model of an existing iPhone app in some simple ways (remove attribute, add attribute, remove index), and can use automatic lightweight migration to migrate the persistent store.

由于数据集的典型大小，处理时间并非微不足道，并且需要为用户提供反馈.

Due to the typical size of the data set, the processing time is not insignificant, and warrants feedback for the user.

NSMigrationManager 提供了一个简单但有用的 migrationProgress 值，可在执行迁移时发送 KVO 通知.这构成了提供反馈的基础，但是尝试使用推断模型 ([NSMappingModel inferredMappingModelForSourceModel:destinationModel:error:]) 会导致完全相同的数据集的时间完全不同.

NSMigrationManager provides a simple but useful migrationProgress value that sends KVO notifications as the migration is performed. That forms the basis of providing feedback, however attempting to use an inferred model ([NSMappingModel inferredMappingModelForSourceModel:destinationModel:error:]) results in drastically different timing for the exact same dataset.

原始 iPhone (2G) 上的配置文件结果，缓存大小:磁盘上的 1.785 MB.

Profile results on an original iPhone (2G), Cache size: 1.785 MB on disk.

自动推断的轻量级迁移

PROFILE: CacheManager -migrateStore
PROFILE:   0.6130 (+0.6130) models loaded
PROFILE:   1.1759 (+0.5629) delegate -CacheManagerWillMigrate:
PROFILE:   1.2516 (+0.0757) persistent store coordinator loaded
PROFILE:   5.1436 (+3.8920) automatic lightweight migration completed
PROFILE:   5.5435 (+0.3999) delegate -CacheManagerDidFinishMigration:withError:

手动推断迁移

PROFILE: CacheManager -migrateStore
PROFILE:   0.6660 (+0.6660) models loaded
PROFILE:   1.1471 (+0.4811) inferred mapping model generated
PROFILE:   1.4046 (+0.2574) delegate -CacheManagerWillMigrate:
PROFILE:   1.5058 (+0.1013) persistent store coordinator loaded
PROFILE:   22.6952 (+21.1894) manual migration completed
PROFILE:   23.1478 (+0.4525) delegate -CacheManagerDidFinishMigration:withError:

因此，使用推断模型，手动迁移的时间是自动迁移的 5 倍以上！

So, with an inferred model, the manual migration takes over 5 times longer than automatic!

更新:模型加载

<的核心数据文档代码>NSPersistentStoreCoordinator "迁移选项" 说:

NSInferMappingModelAutomaticallyOption

...协调器将尝试如果没有，则推断映射模型找到了.

... the coordinator will attempt to infer a mapping model if none can be found.

这就是构建、编译和编译 XCode 的原因.必须删除捆绑的映射模型(或只是取消目标)，以允许进行推断的和轻量级迁移.

And that is why the XCode built,compiled & bundled mapping model has to be removed (or just un-targetted) to allow an inferred and lightweight migration to happen.

这是一个很大的不一致，NSPersistentStoreCoordinator -addPersistentStoreWithType:configuration:URL:options:error: 的 轻量级 选项在处理过程中绝对没有提供任何进度指示.

It's a big inconsistency, and the lightweight option that NSPersistentStoreCoordinator -addPersistentStoreWithType:configuration:URL:options:error: provides absolutely no indication of progress while processing.

任何人都可以提供一种支持的方式来在自动迁移期间获取 migrationProgress 值，或一种将推断映射模型配置为在手动处理期间与自动处理期间一样快的方法?

Can anybody provide a supported way to get the migrationProgress values during automatic migration, OR a way to configure an inferred mapping model to be as fast during manual processing as automatic?

更新:错误报告

与 WWDC 的工程师交谈，他们要求提供错误报告，要求 migrationProgress 进行自动轻量级迁移处理.

Spoke to the engineers at WWDC and they've asked for a bug report requesting the migrationProgress for the automatic lightweight migration processing.

如果更新 API 以添加进度报告，我会再次更新..

I'll update again if the API is updated to add progress reporting..

推荐答案

目前 Core Data 使用私有类 NSSQLiteInPlaceMigrationManager 来执行轻量级迁移.这是 NSMigrationManager 的子类，但在 migrateStoreFromURL:type:options:withMappingModel:toDestinationURL:destinationType:destinationOptions:error: 中自行处理所有内容.从外观上看，这个类实际上是直接在 SQLite 存储上执行更改，而不是按照手动迁移的要求将所有内容都拉入内存.

Currently Core Data uses a private class, NSSQLiteInPlaceMigrationManager, to perform lightweight migration. This is a subclass of NSMigrationManager, but handles everything itself in migrateStoreFromURL:type:options:withMappingModel:toDestinationURL:destinationType:destinationOptions:error:. From the looks of it, this class is actually performing alterations directly on the SQLite store instead of pulling everything into memory as required by manual migration.

这解释了为什么您看到轻量级迁移完成得更快.

This explains why you're seeing the lightweight migration complete much faster.

不幸的是，即使您使用这些在幕后使用的私有 API 的知识，也无法获得进度指示.NSSQLiteInPlaceMigrationManager 的进度值目前从未改变，它始终为零.currentEntityMapping 的值似乎也保持为零.

Unfortunately, even if you use this knowledge of the private APIs that are being used behind the scenes, it doesn't gain you much for getting a progress indication. The value of progress is currently never changed for NSSQLiteInPlaceMigrationManager, it's always zero. The value of currentEntityMapping also seems to remain nil.

在 Apple 提供 API 之前，我们似乎不太走运.你有雷达号码，我可以打开一个副本吗?

Until Apple provides an API, it seems we're out of luck. Do you have a radar number so I can open a duplicate?

这篇关于核心数据推断迁移——自动“轻量级"与手动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！