2

I am new to iOS programming but have done SQL stuff for years. I am trying to use Core Data to build my model. Following the tutorials I have created a schema for my application that involves a number of one-to-many relationships that are not bi-directional.

For example I have a Games entity and a Player entity. A Game includes a collection of Players. Because a Player can be involved in more than one game, an inverse relationship does not make any sense and is not needed.

Yet when I compile my application, I get Consistency Error messages in two forms. One says.

Game.players does not have an inverse; this is an advanced setting.

Really? This is an "advanced" capability enough to earn a warning message? Should I just ignore this message or am I actually doing something wrong here that Core Data is not designed to do?

The other is of the form Misconfigured Property and logs the text:

Something.something should have an inverse.

So why would it think that?

I can't find any pattern to why it picks one error message over the other. Any tips for an iOS newb would be appreciated.

This is under Xcode 5.0.2.

AlanObject
  • 8,408
  • 18
  • 72
  • 122
  • possible duplicate of [Does every Core Data Relationship have to have an Inverse?](http://stackoverflow.com/questions/764125/does-every-core-data-relationship-have-to-have-an-inverse) – Leo Natan Jan 01 '14 at 17:18
  • Yes I guess it is a close duplicate. However I think Marcus Zarra's answer below adds something as I will explain there. – AlanObject Jan 01 '14 at 20:52

2 Answers2

10

Core Data is not a database. This is an important fact to grasp otherwise you will be fighting the framework for a long time.

Core Data is your data model that happens to persist to a database as one of its options. That is not its main function, it is a secondary function.

Core Data requires/recommends that you use inverse relationships so that it can keep referential integrity in check without costly maintenance. For example, if you have a one way between A and B (expressed A --> B) and you delete a B, Core Data may need to walk the entire A table looking for references to B so that it can clean them up. This is expensive. If you have a proper bi-directional relationship (A <-> B) then Core Data knows exactly which A objects it needs to touch to keep the referential integrity.

This is just one example.

Bi-directionality is not required but it is recommended highly enough that it really should be considered a requirement. 99.999% of the time you want that bi-directional relationship even if you never use it. Core Data will use it.

Marcus S. Zarra
  • 46,143
  • 9
  • 99
  • 181
  • I think this is the best direct answer to this question. So Core Data is not an SQL data base and shouldn't be treated as such. Having looked again into the Apple documentation it does have a section on "What Core Data Is Not" but it doesn't say it exactly this way. – AlanObject Jan 01 '14 at 20:54
2

Why not just add the inverse relationship? It can be to-many as well, and you may well end up using it - often fetch requests or object graph navigation works faster or better coming from a different end of a relationship.

Core Data prefers you to define relationships in both directions (hence the warnings) and it costs you nothing to do so, so you may as well. Don't fight the frameworks - core data isn't an SQLLite "manager", it is an object graph and persistence tool, that can use SQL as a back end.

jrturton
  • 113,418
  • 30
  • 247
  • 261