iphone - 如何只获取对象 ID，还包括 CoreData 中的行数据？

Question

In the CoreData Apple Docs on working in the background ，我遇到了这条建议:

For example, you can configure a fetch request to return just object IDs but also include the row data (and update the row cache)—this can be useful if you're just going to pass those object IDs from a background thread to another thread.

我想知道您如何实现这个获取请求？具体如何更新行缓存。

我认为这就是获取 ID 的方法:

NSFetchRequest* request = [NSFetchRequest fetchRequestWithEntityName:@"MyItem"]; // iOS 5 method
request.returnsObjectsAsFaults = YES; 

剩下的我该怎么做？

Answer 1

默认情况下，includesPropertyValues 为 YES，returnsObjectsAsFaults 也为 YES。

如果你只想返回对象ID，你需要使用...

fetchRequest.resultType = NSManagedObjectIDResultType;

但是，没有要获取的属性，也不会填充行缓存。您只会得到一堆对象 ID。

请注意，默认情况下，(resultType == NSManagedObjectResultType)，因为 includesPropertyValues 和 returnsObjectsAsFaults 都是 YES，提取将返回对象作为错误(对象 ID 可访问)，并且行缓存将被填充 - 但数据不会真正“在内存中”，因为该对象仍然是错误的……但您仍然可以获取其对象 ID。

然后您需要做的就是向对象询问其 objectID。

所有这一切，我想，就是说您要求的行为是您默认获得的行为。那么，您是遇到问题了，还是出于某种原因认为自己没有出现这种行为？

编辑

嗯……我是说默认情况下，你会得到你想要的。如果您只是填写一个提取请求，并且不更改任何属性，则 returnsObjectsAsFaults 为 YES——因此返回给您的对象将是错误的。此外，includesPropertyValues 也是 YES —— 因此一些属性数据将在行缓存中可用。

您可以通过调用 managedObject.objectID 来访问 objectID 属性。

编辑

我很抱歉，因为我显然没有做好沟通工作，因为这将是我第三次说同样的话。

当您创建一个 NSFetchRequest 时，它有几个默认设置的属性。

resultType 默认设置为 NSManagedObjectResultType。这意味着，除非你改变它，否则它仍然是 NSManagedObjectResultType。这也意味着您从获取中获得的结果数组将包含一个 NSManagedObjects 数组(而不是返回一个计数、字典或 ObjectID)。

returnsObjectsAsFaults 默认设置为 YES。这意味着，除非您更改它，否则它仍然是 YES。这也意味着从提取中返回的对象将是错误的。 NSManagedObject 不会用属性数据来实现。该对象将是一个故障。它将有足够的元数据来了解其类型、对象 ID 和一些其他内容。

includesPropertyValues 默认设置为 YES。这意味着，除非您更改它，否则它仍然是 YES。这也意味着一些属性数据将被提取到行缓存中。

从获取中返回的每个 NSManagedObject 将:

1. 有对象 ID
2. 是一个错误，所以数据实际上并没有完全加载到内存中
3. 一些属性数据将在行缓存中

这就是您所要求的一切。我不确定我还能添加什么(无需再次重复)。

另外，请注意，如果您只需要对象 ID，您可以将 resultType 设置为 NSManagedObjectIDResultType。

直接来自 NSFetchRequest 文档...

includesPropertyValues

You can set includesPropertyValues to NO to reduce memory overhead by avoiding creation of objects to represent the property values. You should typically only do so, however, if you are sure that either you will not need the actual property data or you already have the information in the row cache, otherwise you will incur multiple trips to the database.

During a normal fetch (includesPropertyValues is YES), Core Data fetches the object ID and property data for the matching records, fills the row cache with the information, and returns managed object as faults (see returnsObjectsAsFaults). These faults are managed objects, but all of their property data still resides in the row cache until the fault is fired. When the fault is fired, Core Data retrieves the data from the row cache—there is no need to go back to the database.

If includesPropertyValues is NO, then Core Data fetches only the object ID information for the matching records—it does not populate the row cache. Core Data still returns managed objects since it only needs managed object IDs to create faults. However, if you subsequently fire the fault, Core Data looks in the (empty) row cache, doesn't find any data, and then goes back to the store a second time for the data.

和...

returnsObjectsAsFaults

The default value is YES. This setting is not used if the result type (see resultType) is NSManagedObjectIDResultType, as object IDs do not have property values. You can set returnsObjectsAsFaults to NO to gain a performance benefit if you know you will need to access the property values from the returned objects.

By default, when you execute a fetch returnsObjectsAsFaults is YES; Core Data fetches the object data for the matching records, fills the row cache with the information, and returns managed object as faults. These faults are managed objects, but all of their property data resides in the row cache until the fault is fired. When the fault is fired, Core Data retrieves the data from the row cache. Although the overhead for this operation is small, for large datasets it may become non-trivial. If you need to access the property values from the returned objects (for example, if you iterate over all the objects to calculate the average value of a particular attribute), then it is more efficient to set returnsObjectsAsFaults to NO to avoid the additional overhead.