relationshipKeyPathsForPrefetching does not work #300

Closed
opened 2025-12-29 15:28:23 +01:00 by adam · 6 comments
Owner

Originally created by @ruslanskorb on GitHub (Dec 20, 2019).

Hi @JohnEstropia!

I found that relationshipKeyPathsForPrefetching property of NSFetchRequest does not work if we are working with CoreData using CoreStore. The relationship is fulfilled from database only after accessing one of its properties.

I added some code to CoreStoreDemo project to debug it. You can look at it here.

Let me know if I am doing something wrong.

Thanks!

Originally created by @ruslanskorb on GitHub (Dec 20, 2019). Hi @JohnEstropia! I found that `relationshipKeyPathsForPrefetching` property of `NSFetchRequest` does not work if we are working with CoreData using CoreStore. The relationship is fulfilled from database only after accessing one of its properties. I added some code to **CoreStoreDemo** project to debug it. You can look at it [here](https://github.com/JohnEstropia/CoreStore/compare/develop...ruslanskorb:relationshipKeyPathsForPrefetching). Let me know if I am doing something wrong. Thanks!
adam added the wontfixios/compiler bug labels 2025-12-29 15:28:23 +01:00
adam closed this issue 2025-12-29 15:28:24 +01:00
Author
Owner

@JohnEstropia commented on GitHub (Dec 21, 2019):

Looks like a longstanding issue with CoreData: https://stackoverflow.com/questions/34018021/core-data-child-contexts-not-prefetching-relationships/34136655

Since CoreStore doesn't really do anything special here but rely on CoreData's behavior, there's nothing that can be done from our side.

@JohnEstropia commented on GitHub (Dec 21, 2019): Looks like a longstanding issue with CoreData: https://stackoverflow.com/questions/34018021/core-data-child-contexts-not-prefetching-relationships/34136655 Since CoreStore doesn't really do anything special here but rely on CoreData's behavior, there's nothing that can be done from our side.
Author
Owner

@ruslanskorb commented on GitHub (Dec 22, 2019):

@JohnEstropia It’s a good time to think about #149 again.

@ruslanskorb commented on GitHub (Dec 22, 2019): @JohnEstropia It’s a good time to think about #149 again.
Author
Owner

@ruslanskorb commented on GitHub (Dec 22, 2019):

@JohnEstropia I would also like to note that this is not an iOS bug. Considering the architecture of NSPersistentContainer we can say that the current architecture does not match the one it should be. And hence arise all the "bugs".

@ruslanskorb commented on GitHub (Dec 22, 2019): @JohnEstropia I would also like to note that this is not an iOS bug. Considering the architecture of `NSPersistentContainer` we can say that the current architecture does not match the one it should be. And hence arise all the "bugs".
Author
Owner

@JohnEstropia commented on GitHub (Dec 24, 2019):

I disagree that this would be something worth changing the current architecture for. If anything, I might encapsulate NSFetchRequest internally so that only working properties can be set from the interface layer.

I've played with NSPersistentContainer's behavior enough to be able to say that it is very simplistic and has a lot more risk for merging conflicts and performance hiccups (which is why CoreStore's architecture was chosen in the first place).

See: https://dmtopolog.com/stranger-things-with-core-data-stacks-comparison/

@JohnEstropia commented on GitHub (Dec 24, 2019): I disagree that this would be something worth changing the current architecture for. If anything, I might encapsulate `NSFetchRequest` internally so that only working properties can be set from the interface layer. I've played with `NSPersistentContainer`'s behavior enough to be able to say that it is very simplistic and has a lot more risk for merging conflicts and performance hiccups (which is why CoreStore's architecture was chosen in the first place). See: https://dmtopolog.com/stranger-things-with-core-data-stacks-comparison/
Author
Owner

@ruslanskorb commented on GitHub (Dec 24, 2019):

@JohnEstropia Thanks for your feedback. I would like to note only that what you called the iOS bug is not an iOS bug.

@ruslanskorb commented on GitHub (Dec 24, 2019): @JohnEstropia Thanks for your feedback. I would like to note only that what you called the iOS bug is not an iOS bug.
Author
Owner

@JohnEstropia commented on GitHub (Jan 8, 2020):

CoreStore simply passes relationshipKeyPathsForPrefetching to Core Data, so this github issue is by definition a bug report on Core Data. The behavior of NSFetchRequest properties changing depending on the stack architecture is iffy at best. At the very least they should be documented accordingly.

Closing this ticket now, but feel free to continue posting. I'll consider improving the Tweak for a more deterministic API

@JohnEstropia commented on GitHub (Jan 8, 2020): CoreStore simply passes `relationshipKeyPathsForPrefetching` to Core Data, so this github issue is by definition a bug report on Core Data. The behavior of `NSFetchRequest` properties changing depending on the stack architecture is iffy at best. At the very least they should be documented accordingly. Closing this ticket now, but feel free to continue posting. I'll consider improving the `Tweak` for a more deterministic API
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore#300