samvermette
samvermette

Reputation: 40437

Core Data relationship not saved to store

I've got this command line app that iterates through CSV files to create a Core Data SQLite store. At some point I'm building these SPStop objects, which has routes and schedules to-many relationships:

SPRoute *route = (SPRoute*)[self.idTransformer objectForOldID:routeID ofType:@"routes" onContext:self.coreDataController.managedObjectContext];

SPStop *stopObject = (SPStop*)[self.idTransformer objectForOldID:stopID ofType:@"stops" onContext:self.coreDataController.managedObjectContext];
[stopObject addSchedulesObject:scheduleObject];
[stopObject addRoutesObject:route];

[self.coreDataController saveMOC];

If I log my stopObject object (before or after saving; same result), I get the following:

latitude = "45.50909";
longitude = "-73.80914";
name = "Roxboro-Pierrefonds";
routes =     (
    "0x10480b1b0 <x-coredata://A7B68C47-3F73-4B7E-9971-2B2CC42DB56E/SPRoute/p2>"
);
schedules =     (
    "0x104833c60 <x-coredata:///SPSchedule/tB5BCE5DC-1B08-4D11-BCBB-82CD9AC42AFF131>"
);

Notice how the routes and schedules object URL formats differ? This must be for a reason, because further down the road when I use the sqlite store and print the same stopObject, my routes set is empty, but the schedules one isn't.

I realize this is very little debugging information but maybe the different URL formats rings a bell for someone? What could I be doing wrong that would cause this?

EDIT: it seems that one SPRoute object can only be assigned to one SPStop at once. I inserted breakpoints at the end of the iteration and had a look a the sqlite every time and I definitely see that as soon as an SPRoute object (that already had been assigned to a previous stop.routes) is assigned to a new SPStop, the previous stop.routes set gets emptied. How can this be?

Upvotes: 4

Views: 941

Answers (1)

samvermette
samvermette

Reputation: 40437

Well, we had disabled Xcode's inverse relationship's warning which clearly states:

SPStop.routes does not have an inverse; this is an advanced setting (no object can be in multiple destinations for a specific relationship)

Which was precisely our issue. We had ditched inverse relationships because Apple states that they're only good for "data integrity". Our store is read-only so we figured we didn't really need them. We learn now that inverse relationships are a little more than just for "data integrity" :P

Upvotes: 1

Related Questions