0

将新的 NSManagedObject 添加到我的核心数据存储后，我尝试调用：

    if ([managedObjectContext hasChanges] && ![managedObjectContext save:&error]) {

并得到以下异常（奇怪的是我没有错误，结果也是积极的！）

2013-03-15 18:32:09.753 Nick copy[28782:3407] CoreData：Ubiquity：日志文件导出期间发生异常：NSInternalInconsistencyException 保存通知内容：NSConcreteNotification 0x3891b0 {name = _NSSQLCoreTransactionStateChangeNotification; object = (URL: file://localhost/var/mobile/Applications/FCAF7FC6-7DC8-4E0B-A114-38778255CA90/Documents/MyApp.sqlite); userInfo = { "_NSSQLCoreActiveSaveRequest" = ""; "_NSSQLCoreTransactionType" = 2; "_NSSQLCoreTransientSequenceNumber" = 1; }}

我可以从“保存”方法中捕获所有异常，并且应用程序运行良好。只是想知道这是否真的可以节省，因为感觉完全不安全。

编辑：尝试删除对象时的另一个异常：

Catched Exception: Failed to process pending changes before save.  The context is still dirty after 100 attempts.  Typically this recursive dirtying is caused by a bad validation method, -willSave, or notification handler.
4

2 回答 2

0

安全吗？可能不是。该错误表明底层泛在系统未能创建 SQL 日志文件。这可能意味着它未能创建 iCloud 用于同步更改的事务日志。抓住它并继续意味着您的数据可能保存在本地，具体取决于框架代码的详细信息。但这几乎可以肯定意味着 iCloud 不会同步这些更改。更糟糕的是，你很可能会因为同样的原因，未来的保存也会失败。

我不完全确定第二个例外，但它很可能是第一个例外的副作用。

如果您尝试在 iOS5 上使用 Core Data 的内置 iCloud 支持，这只是奇怪的、莫名其妙的错误的开始。我已经完成了大量的 iCloud/Core Data 工作，我真的不推荐在 iOS 5 上使用它。即使 iOS 6 充其量也是冒险的，但问题的可能性比 iOS 5 小。

于 2013-03-15T21:08:44.663 回答
0

不幸的是，我再也找不到线程了，但它告诉我必须确保始终只在创建它们的线程/dispatch_queue 中使用NSManagedObject类。

问题是，如果您确实从不同的队列访问它，它可能会在随机间隔后工作或崩溃。

我确保我只从专用的 dispatch_queue 调用 NSManagedObject 并且从那时起没有记录任何奇怪的异常。

于 2013-03-19T17:51:31.170 回答