ios - 核心数据崩溃 - NSPersistentStoreCoordinator 没有持久存储(损坏的文件)

Question

我看到一些标题为这个的崩溃报告:

NSPersistentStoreCoordinator 没有持久存储(损坏的文件)。它不能执行保存操作。我将持久存储添加到协调器的代码在这里:

    NSURL *applicationDocumentsDirectory = [[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask].lastObject;

    NSURL *storeURL = [applicationDocumentsDirectory URLByAppendingPathComponent:@"myDatabase.sqlite"];

    NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@"myDataModel" withExtension:@"momd"];

    NSManagedObjectModel *managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];

    NSDictionary *storeOptions = @{NSInferMappingModelAutomaticallyOption:@YES,
                                   NSMigratePersistentStoresAutomaticallyOption:@YES,
                                   NSSQLitePragmasOption:@{@"synchronous": @"OFF"}};

    // Create the persistent store.
    self.persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:managedObjectModel];
    NSError *error = nil;
    if (![self.persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
                                                       configuration:nil
                                                                 URL:storeURL
                                                             options:storeOptions
                                                               error:&error])
   {

    }

我已经记录了“addPersistentStoreWithType”调用产生的错误，错误如下:

NSCocoaErrorDomain 259
NSSQLiteErrorDomain = 11;
NSUnderlyingException = "Fatal error. The database at <path> is corrupted. SQLite Error code:11, 'database disk image is malformed'

我认为这意味着核心数据库已损坏且无法恢复。是这样吗？我有一个销毁核心数据库并从我的服务器重新填充的备份计划，但我想知道它是否绝对无法恢复，如果有什么我可以做的，首先要弄清楚为什么会发生这种情况。

一些附加信息:

崩溃报告指出 RAM Free 3-6%，Disk Free 57%，运行 iOS 10 的较新型号手机。开始看到这些报告的应用程序版本也是第一个将轻量级核心数据迁移作为一部分的版本其中，我不确定这是否有所作为。我知道 98% 的用户成功升级到该版本并且迁移没有问题。这是报告中的堆栈跟踪。尽管它说的是“device_locked”，但我知道每次我尝试保存到持久存储时都会发生此崩溃，即使用户在应用程序中也是如此。

Answer 1

1. 看看在没有同步编译指示的情况下您是否可以获得可接受的性能。如果它对您的帮助不大，则无需冒险。

2. 我看到您已经拥有可以有效检测何时出现问题的代码...当您点击它时，您可以通过简单地删除 SHM 和 WAL 文件来查看会发生什么。可能只是那些搞砸了。

3. 如果您确实能够从服务器数据中恢复，而且这种情况确实很少见，那么按照您所说的删除整个数据库也许是可以接受的(如果 #2 没有帮助) .

4. 确保您在主线程上创建存储，并确保迁移在主线程上进行。