Basic data relationships are not stored in storage

I have this command line application that iterates through CSV files to create a SQLite data warehouse. At some point, I create these SPStop objects that have 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 register my stopObject (before or after saving, the 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>" ); 

Please note that the different formats of route and schedule URLs are different? This should be for some reason, because further down the road, when I use sqlite storage and print the same stopObject , my routes set is empty, and schedules are not.

I understand that this is very little debugging information, but maybe different URL formats are ringing someone for a call? What can I do wrong to cause this?

EDIT : It seems that one SPRoute object can only be assigned to one SPStop at a time. I inserted breakpoints at the end of the iteration and looked at sqlite every time, and I definitely see that as soon as the SPRoute object (which was already assigned to the previous stop.routes ) is assigned to the new SPStop, the previous stop.routes set becomes empty. How can it be?

+4
source share
1 answer

Well, we had the Xcode feedback warning disabled, which clearly states:

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

That was our problem. We discarded the inverse relationship because Apple claims that they are only good for "data integrity." Our store is read-only, so we decided that they really didn't need them. Now we learn that the inverse relationship is a little more than just for β€œdata integrity”: P

+1
source

Source: https://habr.com/ru/post/1388212/


All Articles