Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><br/>This is a great question.<br/><br/> ButFirst thing first:<br/>It clearly state in the <a href="https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdRelationships.html" rel="nofollow">documentation</a>:<br/></p> <blockquote> <blockquote> <p>"Important: You must define many-to-many relationships in both directions—that is, you must specify two relationships, each being the inverse of the other. You can’t just define a to-many relationship in one direction and try to use it as a many-to-many. If you do, you will end up with referential integrity problems."</p> </blockquote> </blockquote> <p>Never the less, Lets describe the issue (resulting database)<br/> When defining a to-many relationship, the resulting database does not add an additional table to map the relationship.<br/> It only sets a property on the entity at one end of the to-many relationship equal to the last item that referenced it.<br/></p> <p>Example:</p> <p>Model:<br/> Entity: Department<br/> Relationships: NONE<br/> Properties: name (string)<br/></p> <p>Entity: Employee<br/> Relationships: departments (to-many,no-action)<br/> Properties: name<br/></p> <p>Resulting Database:<br/> ZDEPARTMENT:<br/> Z_PK<br/> Z_ENT<br/> Z_OPT<br/> Z2DEPARTMENTS (int)<br/> ZNAME<br/></p> <p>ZEMPLOYEE:<br/> Z_PK<br/> Z_ENT<br/> Z_OPT<br/> ZNAME<br/></p> <p>This structure will obviously result in data inconsistency.<br/></p> <p>The solution will be to hold an entity: <code>DepartmentEmployee</code> modeling the to-many relationship in both directions but one of them would be unidirectional (Department -> DepartmentEmployee):<br/></p> <p>DepartmentEmployee:<br/> Relationships: department (to-one,no-action), employee (to-one,nullify)<br/></p> <p>and you will have to maintain the table upon deletion of a department object.</p> <p>Hope this made some sense :)</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to force UNIDIRECTIONAL to-many relationship to persist
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDan Shelly
    1. USDan Shelly
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. COPlease see my OQ edit for a formatted comment to your solution. If there is no other solution to force core-data to generate the join table, I may end up granting the bounty to your answer, even if it implies rewriting code to add/delete a join-entity to create/brake a relationship.
      singulars
      1. PO
      1. USMax_B
    2. COI have implemented the joining entity solution on a branch of my code. It works as expected. It is not optimal since the joining entity table is twice as large as the automatically generated joining table (+ Z_PK and Z_ENT). The code is less clean but not much. The only real drawback is that it is now less easy to brake retain cycles. In the normal dept/empl, if you add/modify a bunch of employees, you just need to refault the dept after the save to get rid of employees entities. Now you need to iterate on employees to refault each one which has a retain cycle with its joining entity.
      singulars
      1. PO
      1. USMax_B
    3. COI still don't get **why** CoreData framework is not able to generate and update join table on unidirectional many2many. Or, even better, stays with the inverse relationship requirement but **not to load the full set to update an inverse relationship when it only needs to update a few entries in the join table**
      singulars
      1. PO
      1. USMax_B
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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