Core Data multiple relationships to same entity

Question

I have a data model I'm trying to port from a SQLite based table structure to a Core Data model. My SQLite structure has a Zones table and a TransitLogs table. A TransitLog can have the following (in my sqlite schema) start_zone_id end_zone_id

Each of which is a foreign key to the zones table. This works fine in SQL. But when moving to Core Data I'm having trouble understanding how to model this.

My first attempt has me having two relationships in my TransitLog Entity with a startZone and endZone relationship attributes that point to a Zone (sorry wasn't able to post a screenshot of xcode as this is my first post here)

The question I have is how to handle the inverse relationship for the startZone and endZone relationship attributes. Do I not need them? In the documentation and books I've read on this topic, it's best to always use an inverse relationship but I'm wondering about this particular situation if it doesn't apply. Or am I simply modeling this incorrectly in Core Data.

Thanks for any advice.

Mike

Answer 1

You can have two separate to-many relationships in the Zone entity that point to TransitLog, called something like startLogs and endLogs. Those would be the inverses for startZone and endZone, respectively.

Answer 2

Nontrivial model versioning and migration can be a real time sink - especially the first time. For that reason, as well as that Apple recommends using them, I would recommend adding the inverse relationships.

That said, I have found at least one case where it simply did not make sense to add an inverse relationship - and everything works fine. But in that case there it was (and remains) extremely difficult to find a scenario where the inverse relationship would ever be useful or necessary.

Answer 3

Thanks guys - both answers helped a lot. Westsider is right I currently have no need to traverse from the zone down to the TransitLogs and was why I was wondering. But that being said I guess it is possible that I might need them at some point (thousands of users clamoring for it hopefully ;)) so probably better to model it now.

Thanks again for the answers.