Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First a reply for your comment:<br></p> <blockquote> <blockquote> <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.<br/></p> </blockquote> </blockquote> <p>This is exactly what the department property is doing in the joined relationship.<br/> If you would look at the generated SQLite structure, you will see and additional mapping table between the Employee entity and the Department entity, holding only their <code>int64</code> ids.<br/></p> <p>Now, the given example was:<br/></p> <blockquote> <blockquote> <p>Example</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 not 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. A simple ONE-to-many relationship with no inverse could be easily implemented.<br/> You can look at it as just another property on the object in the 'many' side of the relationship.<br/></p> </blockquote> </blockquote> <p>This example request a ONE-to-many relationship of the kind:<br/> Employee-->>Department (an Employee may belong to many departments)<br/> The inverse is:<br/> Department-->Employee<br/> Since we must not implement a many-to-many relationships without an inverse, we must implement the to-ONE side of the relationship, just to make sure we comply with the implementation of the framework.<br/></p> <p>Re-iterating:<br/> By the documentation we know that no many-to-many relationship will NOT persist without an inverse relationship being defined.<br/> ==><br/> Since we like to model the relationship without an inverse we will model it only as the to-ONE part of the coupling (modelling it as a to-many will violate the persistency promised by the framework)<br/> Think of it as useful for defining files in a folder (a file may not belong to more than one folder), or parent child relationship.<br/> ==><br/> We must define the relationship as:<br/> Department-->Employee (Which does not make much sense since a department that can hold only one employee is not really a department is it)<br/></p> <p>To look at it from another angel (negative proof):<br/> Suppose we would like to go against the framework and define a MANY-to-many relationship with no inverse.<br/> ==><br/> That would mean that we will only implement it in one direction leaving a ... to-many relationship or ... MANY-to relationship<br/> ==><br/> this is the same thing isn't it (a to-many relationship from and entity1 to entity2)<br/> ==><br/> NOW, if we have a ONE-to-many relationship and we choose to not implement the inverse of it, we can choose to implement the to-many part? <strong>NO WE CANNOT</strong>, this will look as only half of a MANY-to-many relationship ==><br/> We <strong>MUST</strong> implement the ONE-to part of it.</p> <p>For making some more sense, I will show the more logical:<br/> Department-->>Employee So our implementation for this ONE-to-many relationship would be:<br/> Department&lt;--Employee</p> <p>This will result in the following SQLite DB structure:<br/> ZDEPARTMENT:<br/> Z_PK<br/> Z_ENT<br/> Z_OPT<br/> ZNAME</p> <p>ZEMPLOYEE:<br/> Z_PK<br/> Z_ENT<br/> Z_OPT<br/> ZDEPARTMENT (int)<br/> ZNAME<br/></p> <p>We could now define a fetched property on Department to fetch all the employees belonging to it:<br/> <code>employees</code> predicate: <code>department == $FETCH_SOURCE</code><br/></p> <p>You can enforce this relationship in the <code>prepareForDeletion</code> method of Department (not tested):<br/> (You will first set the <code>userInfo</code> dictionary on Department to hold the type of enforcement)<br/> (I left the implementation of the 'Deny' rule to the reader :D )<br/></p> <pre><code>- (void) prepareForDeletion { [super prepareForDeletion]; NSEntityDescription* entity = [self entity]; NSDictionary* dict = [entity userInfo] ; if ([dict count]) { [dict enumerateKeysAndObjectsUsingBlock:^(NSString* key, NSString* value, BOOL *stop) { NSArray* arr = [self valueForKey:key]; if( [value isEqualToString:@"cascade"]) { for (NSManagedObject* obj in arr) { [[self managedObjectContext] deleteObject:obj]; } } else if ( [value isEqualToString:@"nullify"] ) { NSArray* arr = [self valueForKey:key]; for (NSManagedObject* obj in arr) { [obj setValue:nil forKey:@"department"]; } } }]; } } </code></pre> <p>As I see it, this is all you can do with regard to inverse relationships. If you still believe you need a many-to-many relationship, please refer to my other answer.</p> <p>Regards,<br/> Dan.</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
    1. COOk. Even if I'm not sure I got everything right from this second answer, I think that the definition of what I want to achieve fall eventually under the forbidden unidirectional many-to-many. Since we can model a solution by explicitly adding the joining entity _DepartmentEmployee_, on which we can have an **unidirectional** to-one relationship to _department_ (to avoid the huge reverse NSSet), it's rather frustrating that it can't be done by the framework. Nevertheless, unless someone else come with another clever tip, I'll probably implement the explicit join entity solution.
      singulars
      1. PO
      1. USMax_B
    2. CO@Kevin Clifton is right, prepareForDeletion is a more suitable place for this deletion logic
      singulars
      1. PO
      1. USDan Shelly
 

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