I have an NSManagedObject A, which has a to many relationship with object B.
If I create object B, and add it to relationship for A TWICE for example
B = get somehow
[A addObjectB:B];
[A addObjectB:B];
Will the graph be still be consistent or do I have to make sure that I do not duplicate relationship in some way? I know it's a set that manages relationship so duplicates should not be allowed, but I just want to make sure.
A "to-many" relationship is represented by a NSSet and is unique.
If you add an object to a relationship set multiple times it will only appear in the relationship once.
Related
When I try to make the inverse relationship of a entity equal to the same as another one to one relationship's inverse I chose, it replaces the other one I chose. Why can't I have multiple?
Because that's how Core Data works. A relationship may (and should) have an inverse relationship. It can't have multiple inverse relationships. If you assign an inverse where one already exists, you replace that inverse. What you're seeing is normal and expected.
I'm new to Core Data and I'm trying to implement it into my existing project. Here is my model:
Now, there's some things that don't make sense to me, likely because I haven't modelled it correctly.
CMAJournal is my top level object with an ordered set of CMAEntry objects and an ordered set of CMAUserDefine objects.
Here's my problem:
Each CMAUserDefine object has an ordered set of objects. For example, the "Baits" CMAUserDefine will have an ordered set of CMABait objects, the "Species" CMAUserDefine will have an ordered set of CMASpecies objects, etc.
Each CMAEntry object has attributes like baitUsed, fishSpecies, etc. that point to an object in the respective CMAUserDefine object. This is so if changes are made, each CMAEntry that references that object is also changed.
Now, from what I've read I should have inverses for each of my relationships. This doesn't make sense in my model. For example, I could have 5 CMAEntry objects whose baitUsed property points to the same CMABait object. Which CMAEntry does the CMABait's entry property point to if there are 5 CMAEntry objects that reference that CMABait? I don't think it should point to anything.
What I want is for all CMAUserDefine objects (i.e. all CMABait, CMASpecies, CMALocation, etc. objects) to be stored in the CMAJournal userDefines set, and have those objects be referenced in each CMAEntry.
I originally had this working great with NSArchiving, but the archive file size was MASSIVE. I mean, 18+ MB for 16 or so entries (which included about 20 images). And from what I've read, Core Data is something I should learn anyway.
So I'm wondering, is my model wrong? Did I take the wrong approach? Is there a more efficient way of using NSArchiver that will better fit my needs?
I hope that makes sense. Please let me know if I need to explain it better.
Thanks!
E: What lead me to this question is getting a bunch of "Dangling reference to an invalid object." = "" errors when trying to save.
A. Some Basics
Core Data needs a inverse relationship to model the relationship. To make a long story short:
In an object graph as modeled by Core Data a reference semantically points from the source object to a destination object. Therefore you use a single reference as CMASpecies's fishSpecies to model a to-one relationship and a collection as NSSet to model a to-many relationship. You do not care about the type of the inverse relationship. In many cases you do not have one at all.
In a relational data base relationships are modeled differently: If you have a 1:N (one-to-many) relationship the relationship is stored on the destination side. The reason for this is, that in a rDB every entity has a fixed size and therefore cannot reference a variable number of destinations. If you have a many-to-many relationship (N:M), a additional table is needed.
As you can see, in an object graph the types of relationships are to-one and to-many only depending on the source, while in rDB the types of relationships are one-to-one, one-to-many, many-to-many depending on both source and destination.
To select the right kind of rDB modeling Core Data wants to know the type of the inverse relationship.
Type Object graph Inverse | rDB
1:1 to-one id to-one id | source or destination attribute
1:N collection to-one id | destination attribute
N:M collection collection | additional table with two attributes
B. To your Q
In your case, if a CMAEntry object refers exactly one CMASpecies object, but a CMASpecies object can be referred by many CMAEntry objects, this simply means that the inverse relationship is a to-many relationship.
Yes, it is strange for a OOP developer to have such inverse relationships. For a SQL developer, it is the usual case. Developing an ORM (object relational mapper) this is one of the problems. (I know that, because I'm doing that for Objective-Cloud right now. But I did if different, more the OOP's point of view.) Every solution is a kind of unusual for one side. Somebody called ORM the "vietnam of software development".
To have a more simple example: Modeling a sports league you will find yourself having a entity Match with the properties homeTeam and guestTeam. You want to have an inverse relationship, no not homeMatches and guestMatches, but simply matches. This is obviously no inverse. Simply add inverse relationship, if Core Data wants and don't care about it.
I have an Entity A which has to-many relationships with Entity B.
Entity A -->> Entity B
I need to refer to the count of to-many relationship, at more than one screen. Further, I can remove and add reference to any Entity B from Entity A multiple times.
Now, the question is : What is the best way to refer the relationship count?
What I observed:?
1] I can make a count attribute in Entity A and increment/decrement it according to the relationship count and then fetch this attribute on screens I need.
2] I can also get the count from count property of NSSet(of relationships), this way I do not have to fetch the EntityA. I can simply do,
NSSet *set = EntityA.EntitiesB;
NSInteger count = set.count;
This way also fetch happens but I do not have to create a fetch request again and again for EntityA.
Appreciate any help.
You don't actually have to fetch anything, you can create your fetch request with suitable predicate and then use countForFetchRequest:error: to get the count. You could also create a fetch request template (setFetchRequestTemplate:forName:) and then use fetchRequestFromTemplateWithName:substitutionVariables: when you need to use it.
Use the count on the relationship. This pattern will also fit better when integrating the relationship into the UI (for example, number of rows in a table view), and is the method seens in apple's sample code. Creating a count attribute would most likely just add unnecessary complexity to your model.
I have a ObjectA which has a one-to-many relationship with ObjectB. ObjectB has an inverse one-to-one with ObjectA. It all seems to go well until I realised that calling [objectA.objectBSet removeAllObjects] breaks the inverse relationship of ObjectB's instances which where inside the Set. objectA.objectBSet is just the NSMutableOrderedSet of the objectBs which I (think) I get from the mogenerator tool (if that makes any difference).
Is this possible or I am doing something wrong? Can it be that simply removing an object from the set of its parent can influence the value of its inverse relationship automatically from CoreData?
Many Thanks
This is how it's supposed to work. If two relationships are inverses, then they must be consistent with each other for every object. If you tell an ObjectA to remove all relationships to instances of ObjectB, then those ObjectB instances will also remove their relationship to that ObjectA. That's how inverse relationships work. If the ObjectB instances still claimed to be related to the ObjectA instance, the inverse relationship would be in an inconsistent state.
If this isn't what you want for some reason, use relationships between ObjectA and ObjectB that are not inverses of each other.
Yes, CoreData will nullify the inverse relationship for you when you remove objects from the Set. Or if you do objectB.objectA = nil it will also remove objectB from objectA's set.
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.
This is to ask if some of you found a trick/workaround to achieve persistence, beside the obvious answer or adding an inverse relationship.
Background:
Even if unidirectional relationship are discouraged in the documentation, they are not forbidden. The doc only insists on responsibility incurred when having no inverse.
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.
Example
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.
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.
Edit: The Join entity solution
This edit is to give more light and discussion to Dan Shelly's answer proposal below.
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:
Unidirectional Relationships
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.
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.
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.
i.e:
DepartmentEmployee:
Properties: Dept_ix (integer)
Relationships: employee (to-one,nullify)
This is a great question.
ButFirst thing first:It clearly state in the documentation:
"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."
Never the less, Lets describe the issue (resulting database)
When defining a to-many relationship, the resulting database does not add an additional table to map the relationship.
It only sets a property on the entity at one end of the to-many relationship equal to the last item that referenced it.
Example:
Model:
Entity: Department
Relationships: NONE
Properties: name (string)
Entity: Employee
Relationships: departments (to-many,no-action)
Properties: name
Resulting Database:
ZDEPARTMENT:
Z_PK
Z_ENT
Z_OPT
Z2DEPARTMENTS (int)
ZNAME
ZEMPLOYEE:
Z_PK
Z_ENT
Z_OPT
ZNAME
This structure will obviously result in data inconsistency.
The solution will be to hold an entity: DepartmentEmployee modeling the to-many relationship in both directions but one of them would be unidirectional (Department -> DepartmentEmployee):
DepartmentEmployee:
Relationships: department (to-one,no-action), employee (to-one,nullify)
and you will have to maintain the table upon deletion of a department object.
Hope this made some sense :)
First a reply for your comment:
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.
This is exactly what the department property is doing in the joined relationship.
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 int64 ids.
Now, the given example was:
Example
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.
You can look at it as just another property on the object in the 'many' side of the relationship.
This example request a ONE-to-many relationship of the kind:
Employee-->>Department (an Employee may belong to many departments)
The inverse is:
Department-->Employee
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.
Re-iterating:
By the documentation we know that no many-to-many relationship will NOT persist without an inverse relationship being defined.
==>
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)
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.
==>
We must define the relationship as:
Department-->Employee (Which does not make much sense since a department that can hold only one employee is not really a department is it)
To look at it from another angel (negative proof):
Suppose we would like to go against the framework and define a MANY-to-many relationship with no inverse.
==>
That would mean that we will only implement it in one direction leaving a ... to-many relationship or ... MANY-to relationship
==>
this is the same thing isn't it (a to-many relationship from and entity1 to entity2)
==>
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? NO WE CANNOT, this will look as only half of a MANY-to-many relationship
==>
We MUST implement the ONE-to part of it.
For making some more sense, I will show the more logical:
Department-->>Employee
So our implementation for this ONE-to-many relationship would be:
Department<--Employee
This will result in the following SQLite DB structure:
ZDEPARTMENT:
Z_PK
Z_ENT
Z_OPT
ZNAME
ZEMPLOYEE:
Z_PK
Z_ENT
Z_OPT
ZDEPARTMENT (int)
ZNAME
We could now define a fetched property on Department to fetch all the employees belonging to it:
employees predicate: department == $FETCH_SOURCE
You can enforce this relationship in the prepareForDeletion method of Department (not tested):
(You will first set the userInfo dictionary on Department to hold the type of enforcement)
(I left the implementation of the 'Deny' rule to the reader :D )
- (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"];
}
}
}];
}
}
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.
Regards,
Dan.
Have you considered doing away with the relationship entirely and programmatically managing the foreign key on employee?
If you have a UI which sets the property from a list of existing Departments (a pick list, etc.) you can simply take the primary key from that list and assign it as the departmentID property on your Employee.
You should then be able to implement a validateDepartmentID:error method on your Employee object which checks that the given departmentID is valid (i.e. is in a fetched list of departments) and/or is not null so that you maintain referential integrity between the Employee and Department.
When fetching the list of Employees in a Department, you can either use fetched properties or add an instance method to the Department which returns an instance of NSFetchedResultsController containing the Department's employee list.
The only other thing you'd need to do is inject some deletion logic in your Department class (likely on -prepareForDeletion) to update the departmentID on any affected child records. That one depends on your business logic.
The Apple docs on property validation cover -prepareForDeletion and -validateValue:forKey:error if you're not familiar with them.