You can use this feature to restrict the working set of data in your application. (In database terms, this is an in-memory cursor.) The array returned from executing the request is a proxy object that transparently faults batches on demand. When the fetch is executed, the entire request is evaluated and the identities of all matching objects recorded, but only data for objects up to the batchSize will be fetched from the persistent store at a time. If you set a nonzero batch size, the collection of objects returned when an instance of NSFetchRequest is executed is broken into batches. Needless to say, the documentation doesn’t mention this, but it does do a good job of explaining what fetchBatchSize does: Similarly for fetch requests with batching enabled, you do not want a Swift Array but instead an NSArray to avoid making an immediate copy of the future. Perhaps the answer is to provide a duplicate set of NSSet accessors for use when you want the lazy behavior enabled by the class cluster. It’s so convenient, though, and often it doesn’t matter because it’s a small relationship or one that you will be fully accessing anyway. This loads the entire relationship up front and fulfills the Future all the time, immediately. Declaring an accessor as Set forces an immediate copy of the entire relationship so it can be an immutable Swift Set. This lets us optimize memory and performance across your object graph. The concrete instance is a future subclass however. These are reference types expressed as NSSet.
Core Data makes heavy use of Futures, especially for relationship values. We do not recommend making Core Data relationships typed this way despite the obvious convenience. Making NSFetchRequest.fetchBatchSize Work With Swift
0 kommentar(er)
