是否有必要调用 NSManagedObjectContext save: 用于内存存储?
Posted
技术标签:
【中文标题】是否有必要调用 NSManagedObjectContext save: 用于内存存储?【英文标题】:Is it necessary to call NSManagedObjectContext save: for in-memory stores? 【发布时间】:2013-05-10 10:03:13 【问题描述】:我在我的应用程序中使用 CoreData,具有 NSInMemoryStoreType
类型的持久存储。
这种类型的商店有必要打电话给NSManagedObjectContext save:
吗?将save:
传递给NSManagedObjectContext
实际上对内存存储有任何作用吗?
Apple's documentation 简单地说:
保存: 尝试将对已注册对象的未保存更改提交到其持久存储。
在内存存储的上下文中这实际上意味着什么?
【问题讨论】:
+1,非常好的问题。我一直保存上下文,相信在上下文中创建的所有对象都会被移动到 persistentStore 并会减少内存占用。 【参考方案1】:我找不到任何文档,但我确信它仍然需要。
Core Data
有一个内存前端(由托管对象上下文表示)和一个持久后端(“存储”)。持久化后端通常是一个文件,但它可以只驻留在内存中以供 NSInMemoryStoreType
使用。
要使所有Core Data
功能正常工作,必须将这两个部分分开,并通过save
操作从前端(待更改)推送到后端(持久数据)。
请注意,同一存储(后端)可以有多个托管对象上下文(前端),并且每个都具有不同的待处理更改。请注意,每个托管对象上下文都有 hasChanges
和 NSUndoManager
之类的方法。它仍然适用于内存存储。
还有一些信息here
【讨论】:
【参考方案2】:save:
执行属性和关系约束的验证。
【讨论】:
以上是关于是否有必要调用 NSManagedObjectContext save: 用于内存存储?的主要内容,如果未能解决你的问题,请参考以下文章
在这种情况下是不是有必要调用 flush()(JPA 接口)?
Android系统中Bitmap是不是有调用recycle方法的必要性
当我进行异步调用时,是不是有必要在 iOS 和 Android 的 while 循环中使用 Thread.Sleep(1)?