StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POHow to force UNIDIRECTIONAL to-many relationship to persist
text
Body
copied!<p>There is a problem with core data when a to-many relationship has no inverse. Changes made to the related property do not persist. This is a problem many of us have faced, as it can be found by googling.</p> <p>This is to ask if some of you found a trick/workaround to achieve persistence, beside the obvious answer or adding an inverse relationship.</p> <p><strong>Background</strong>:</p> <ul> <li>Even if unidirectional relationship are discouraged in the documentation, they are not forbidden. The doc only insists on responsibility incurred when having no inverse.</li> <li>The reason of not wanting an inverse is outlined in the core-data doc: when you have a large number of items linked to one entity the inverse relationship is loading a large NSSet each time an item is added. Consuming memory, possibly more than allowed for no reason.</li> </ul> <p><strong>Example</strong></p> <p>In employees/department typical paradigm, if you have a huge number of employees able to belong to several departments, you need a to-many relationship from employee to department. You do <strong>not</strong> want the inverse because each time an employee is linked to a department, a (very) large NSSet must be loaded, updated and saved. Moreover if the department entity is never deleted, graph integrity is easy to maintain.</p> <p>Please do not reply that this is a feature of core-data and that inverse relationship is mandatory. This is not stated as such and is more like a bug than a feature. Posting a bug report is not solving the point for current deployed systems.</p> <p><strong>Edit: The Join entity solution</strong> This edit is to give more light and discussion to Dan Shelly's answer proposal below.</p> <p>First, to reply to your first, I'm not trying to have a many-to-many but a true unidirectional to-many. The very same page your linked has this text a bit below the one you quoted: </p> <blockquote> <p><strong>Unidirectional Relationships</strong></p> <p>It is not strictly necessary to model a relationship in both directions. In some cases it may be useful not to, for example when a to-many relationship may have a very large number of destination objects and you are rarely likely to traverse the relationship (you may want to ensure that you do not unnecessarily fault in a large number of objects at the destination of a relationship). Not modeling a relationship in both directions, however, imposes on you a great number of responsibilities, to ensure the consistency of the object graph, for change tracking, and for undo management.</p> </blockquote> <p>That said your proposed solution of adding an join entity is a way to go if there is no solution to force core-data to generates and updates it automatically.</p> <p>IMO, and for my use case, the join entity does not even need to have the relationship to Department. This to-one is useless and may be replaced by a property of the join entity keeping related Department information, like its objectID or other indexed property to reach it.</p> <p>i.e:<br> DepartmentEmployee:<br> Properties: Dept_ix (integer)<br> Relationships: employee (to-one,nullify)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload