2

I'm facing this strange issue when trying to fetch some objects after their objectID. The error complains that there is no such thing as an objectID key path, but the managed object should respond to that. The error is not thrown all the time, which makes me think it could be a concurrency problem, although I've double checked and each context performs the operations on its own thread.

Here is the predicate, although it looks sane to me: [NSPredicate predicateWithFormat:@"objectID == %@", book.objectID]

Edit: Regarding this answer. I didn't tried using the object itself, I need to use the objectID because of multithreading considerations.

Community
  • 1
  • 1
Rad'Val
  • 8,895
  • 9
  • 62
  • 92
  • 1
    the answer given still hold for this case. although strange, CoreData allow comparison of objects to their `objectID` in a predicate as this is how they are identified in any case. – Dan Shelly Apr 22 '14 at 22:47
  • @DanShelly not sure what you mean by "still hold", sharing managed objects between threads doesn't seem like a good idea – Rad'Val Apr 22 '14 at 22:54
  • I did not said you should share managed objects between threads. I meant that you could still use the predicate given in the linked answer, but provide it your object ID as parameter: `@"SELF = %@",book.objectID` – Dan Shelly Apr 22 '14 at 22:58
  • 1
    @DanShelly Strange enough, that works. Thanks! Any idea why? If you make your comment an answer I'll accept it. – Rad'Val Apr 22 '14 at 23:07

1 Answers1

11

The answer given in THIS link still holds here.
It holds in the sense that you use the same predicate:

NSPredicate* p = [NSPredicate predicateWithFormat:@"SELF = %@",book.objectID];

But you supply the objectID as parameter.

CoreData allow comparison of objectIDs and objects when fetching from the store. it probably has to do with the fact that an objectID is used for a one-to-one mapping to a managed object (hence the use of SELF which is a predicate reserved word and not a property name).

Community
  • 1
  • 1
Dan Shelly
  • 5,991
  • 2
  • 22
  • 26
  • Another example of an obscure behavior of Core Data. I wonder is this even documented anywhere? I've been struggling with this error until I found your comment. – Stan Mots May 02 '19 at 19:15