0

I'm trying to be a "good little programmer" and implement inverses for all relationships in my core data model. However, I've come across a situation that makes this seem impractical.

For simplicity, consider a general-purpose entity type called Location that contains an x attribute and a y attribute (and might contain other attributes, but let's keep it simple). Several different entity types may need to keep up with one or more location (players have an original location and a current location, cells have locations, destinations have locations, etc). Given all the different uses for such a general type, it seems impractical to make an inverse relationship in the location entity type for every instance in which it's used in other entities.

Is there an better alternative in Core Data for implementing a very general-purpose entity type that would prevent the need for relations without inverses?

FTLPhysicsGuy
  • 821
  • 1
  • 10
  • 21
  • I'm currently working on an app that leverages Core Data with an entity which does not have an inverse. I, too, was concerned about this and found the following SO post helpful: http://stackoverflow.com/questions/764125/does-every-core-data-relationship-have-to-have-an-inverse Apple's Core Data Programming Guide under "Unidirectional Relationships" states "It is not strictly necessary to model a relationship in both directions." I didn't have any success finding alternatives previously, but I also haven't had any issues with the unidirectional relationships in my app either. Hope this helps. – Derek Lee Oct 29 '14 at 04:58
  • Thanks for the comment. I'm guessing that I'll either have to deal with unidirectional relationships or force an inverse relationship for every use of my general-purpose entity type. I could make the location a transformable attribute, but I that imposes restrictions (e.g., remove search functionality), which I need to keep intact. I really wish Core Data had a regular way to handle this type of pattern -- there must be plenty of examples where a general purpose entity type would be useful but gets cumbersome if you have to add an inverse relationship to it every time you want to use it – FTLPhysicsGuy Oct 30 '14 at 01:26

1 Answers1

1

Having received no answers, I'll share the pattern I started using to help in this situation:

Basically, I derive an entity type from the general-purpose entity type for each specific use, and then I can make relationships and inverse relationships to the derived entity type as appropriate.

For example, I can have a PlayerLocation entity type and a PlayerOrigin entity type, both with the general purpose "Location" as their parent entity type (so in object-oriented-think, they become classes derived from a Location base class). Then a Player entity type can have a to-one relationship (location) to a PlayerLocation and a to-one relationship (origin) to a PlayerOrigin, and each of those derived location types can have unique inverse relationships (owner) pointing back to the Player. Here's a pictorial:

enter image description here

This may cause me to create many more entity types than I originally envisioned, but it makes for a pretty clean object model with specific entity types that have clear relationships and inverse relationships.

Hope that helps others.

FTLPhysicsGuy
  • 821
  • 1
  • 10
  • 21