StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>This is a classic Core Data problem. The docs specifically state:</p> <blockquote> <p>Since Core Data takes care of the object graph consistency maintenance for you, you only need to change one end of a relationship and all other aspects are managed for you. </p> </blockquote> <p>However, in practice this is a bald-faced lie, in that it is unreliable.</p> <p>My answers to your questions is thus:</p> <blockquote> <p>Is this a bug in Core Data?</p> </blockquote> <p>YES.</p> <blockquote> <p>Is this documented behaviour which I have missed? </p> </blockquote> <p>NO.</p> <blockquote> <p>Am I using Core Data in ways it was not intended?</p> </blockquote> <p>NO.</p> <p>You have already provided the "correct" solution to your problem, the same solution which I use every single time I change relationship values in every single Core Data app I make. For literally hundreds of cases, the recommended pattern is:</p> <pre><code>[department setValue:employee forKey:@"employee"]; [employee setValue:department forKey:@"department"]; </code></pre> <p>ie, set the relationship inverse yourself whenever you change the relationship.</p> <p>Someone may have more light on this subject, or a more canon form for working around your issue, but in my experience there is no way to guarantee that a relationship is actively available unless it is manually established (as your problem shows). More importantly, this solution also has two other benefits:</p> <ol> <li>It works 100% of the time.</li> <li>It makes the code more readable.</li> </ol> <p>The last point is counter-intuitive. On the one hand, it seems to complicate the code and make it longer by adding lines to what could be, according to the docs, a short, one-line call. But in my experience what it does is save a trip by the programmer to the Core Data editor to visually hunt down and confirm model relationships, which is more valuable time-wise. It's better to be clear and explicit vs having a mental-model of what is supposed to happen when changing a relationship.</p> <p>I would also suggest adding a simple category to NSManagedObject:</p> <pre><code>@interface NSManagedObject (inverse) - (void)setValue:(id)value forKey:(NSString *)key inverseKey:(NSString *)inverse; @end @implementation NSManagedObject (inverse) - (void)setValue:(id)value forKey:(NSString *)key inverseKey:(NSString *)inverse { [self setValue:value forKey:key]; [value setValue:self forKey:inverse]; } @end </code></pre> <p>as in:</p> <pre><code>[department setValue:employee forKey:@"employee" inverse:@"department"]; </code></pre> <p>there are a few cases to expand upon that category but I would handle, for example, deletion in a different fashion altogether.</p> <p><strong>In short:</strong> <em>handle all your own relationships explicitly every time.</em> Core Data is not trustworthy in this regard.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload