returnsObjectsAsFaults is not working with fetch tweak #251

Closed
opened 2025-12-29 15:27:37 +01:00 by adam · 1 comment
Owner

Originally created by @iby on GitHub (Jan 9, 2019).

I'm trying to do batch faulting using returnsObjectsAsFaults… with no success! ☹️ I tried this on my own data and with TimeZones demo. Using the README tweak example I've updated the FetchingAndQueryingDemoViewController.swift#L165-L171 with:

fetch: { () -> [TimeZone] in
    let result = Static.timeZonesStack.fetchAll(
        From<TimeZone>()
            .orderBy(.ascending(\.name))
            .tweak({
                $0.includesPendingChanges = false
                $0.returnsObjectsAsFaults = false
                $0.includesSubentities = false
            })
    )!
    
    Swift.print(result.first)
    
    return result
}

This however yields unexpected faulted timezone object:

<CoreStoreDemo.TimeZone: 0x600001a90190> (entity: TimeZone; id: 0xbc0d8d8662933916 <x-coredata://C0A6E032-ABFE-41C1-AD0F-CE41BC74CF8B/TimeZone/p1339> ; data: <fault>)

Looking into this deeper I found a clue on StackOverflow but can't find publicly accessible persistent coordinator in stack nor store, so can't test it out:

One common reason is, if your fetch request is executed from a child context who answers to a parent context rather than directly to the persistent coordinator. Try moc.persistentCoordinator.fetch... instead of moc.fetch...

Can you confirm whether this is the case? Is there a workaround? ✌️

Originally created by @iby on GitHub (Jan 9, 2019). I'm trying to do [batch faulting](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/Performance.html#//apple_ref/doc/uid/TP40001075-CH25-SW8) using `returnsObjectsAsFaults`… with no success! ☹️ I tried this on my own data and with TimeZones demo. Using the [README tweak example](https://github.com/JohnEstropia/CoreStore#tweak-clause) I've updated the [FetchingAndQueryingDemoViewController.swift#L165-L171](https://github.com/JohnEstropia/CoreStore/blob/8c30ec3a3d01159f7869700374d03c6a86bcdfec/CoreStoreDemo/CoreStoreDemo/Fetching%20and%20Querying%20Demo/FetchingAndQueryingDemoViewController.swift#L165-L171) with: ```swift fetch: { () -> [TimeZone] in let result = Static.timeZonesStack.fetchAll( From<TimeZone>() .orderBy(.ascending(\.name)) .tweak({ $0.includesPendingChanges = false $0.returnsObjectsAsFaults = false $0.includesSubentities = false }) )! Swift.print(result.first) return result } ``` This however yields unexpected faulted timezone object: ```sh <CoreStoreDemo.TimeZone: 0x600001a90190> (entity: TimeZone; id: 0xbc0d8d8662933916 <x-coredata://C0A6E032-ABFE-41C1-AD0F-CE41BC74CF8B/TimeZone/p1339> ; data: <fault>) ``` Looking into this deeper I found a clue on [StackOverflow](https://stackoverflow.com/q/49415076/458356#comment85833739_49415076) but can't find publicly accessible persistent coordinator in stack nor store, so can't test it out: > One common reason is, if your fetch request is executed from a child context who answers to a parent context rather than directly to the persistent coordinator. Try moc.persistentCoordinator.fetch... instead of moc.fetch... Can you confirm whether this is the case? Is there a workaround? ✌️
adam added the wontfixios/compiler bug labels 2025-12-29 15:27:37 +01:00
adam closed this issue 2025-12-29 15:27:37 +01:00
Author
Owner

@JohnEstropia commented on GitHub (Jan 10, 2019):

Yes, the read-only context is currently a child of the write-only context.

Not sure how to work around this issue though, or wether this is a bug or not. In my understanding the returnsObjectsAsFaults is a hint that properties can be prefetched, but there might be conditions where CoreData would ignore this altogether.

@JohnEstropia commented on GitHub (Jan 10, 2019): Yes, the read-only context is currently a child of the write-only context. Not sure how to work around this issue though, or wether this is a bug or not. In my understanding the `returnsObjectsAsFaults` is a hint that properties can be prefetched, but there might be conditions where CoreData would ignore this altogether.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore#251