In Core Data I have a House Entity which has a relationship to a Room entity. The Room entity itself has a many-to-many relationship with a Door entity.
Two rooms might share the same door, so here is what I need to know:
Is it possible to have two Room entities with a relationship to the same Door entity. And when updating the properties of the Door entity, it will be the same object and gets updated in both Room entities.
Is it possible to move the Door entity from one relationship to another, without copying it?
You have a many-to-many relationship between Room and Door. This means that those relationships behave as a Set, so you can call myDoor.doors.remove(room), or .insert() to manage the entity. These are reciprocal as well, like all Core Data relationships (see here for further details). Do note your naming scheme is a bit confusing, and for example I'd recommend switching to using myDoor.rooms
Related
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'm struggling with creating a suitable Core Data model for my app. I'm hoping someone here can provide some guidance.
I have two entities -- "Goals" and "Items". The Goals entity contains only a goal description, but any goal may have any number of subgoals, and these may extend multiple levels in a tree structure. Subgoals are to be contained within the same entity, so presumably the Goal entity will contain a pointer to "parent" which will be the parent goal of any subgoal.
There will also be an "Items" entity that contains a couple of text fields and a couple of binary items, and must be linked (ideally, by a unique identifier, perhaps objectID) to the particular goal or subgoal the item(s) are related to.
I am totally fumbling with how to set this model up. I know what attributes need to be in each entity, but the relationships, particularly between goals and "subgoals", has me stumped. I don't seem to be able to turn up any good examples of tree structures in Core Data on the Internet, and even the couple of books I have on Core Data don't seem to address it.
Can anyone here help an old SQL programmer get headed the right direction with these relationships in Core Data? Thanks.
Have you tried creating a one-to-many from Goal to itself, and a one-to-one from Goal to Item? The only thing I would worry about here is circular references.
Also, read Relationships and Fetched Properties in the CoreData Programming Guide.
Here is how it is done:
You set up a to-many relationship from Goal to Item in the model editor. Don't use any ids, foreign keys etc. This is old-fashioned database thinking - you can forget about it. Here we are only dealing with an object graph. The database layer is just an implementation detail for persisting the data.
Make two more relationships in entity Goal to itself: a to-one called parent, a to-many called subGoals. Make them the inverse of each other. Simple!
QED is correct, you can create a to many relationship on goal (call it subgoals) as well as a to-one relationship on goal (call it parentGoal) and set them as inverses to each other.
Then create another to many relationship (call it items) on the goal entity, with the inverse being a to one relationship on the item entity (call it goal). Then you're all set. You don't need to link items with a unique id, just add them to the items relationship.
Also note that if you did want to give items a unique id, do not use the objectID. The objectID should only be used as a temporary id as they are not guaranteed to remain the same. In fact they will change if you ever do a Core Data migration.
One way, though not really great, is to create a another entity, say subGoal, and each goal has one subGoal and each object of subGoal has many goal.
I've been studying Core Data quite a bit now, and I've now decided it's time to use it in a new project I'm doing.
Having never use it in a working project I've just come across a few issues I would like to get the communities feedback on.
I'm doing a location based application and I would like to store "outings" in my Core Data model, so for each trip I have some traditional information such as date, distance, description etc... But I also need to save location information which I'll need to plot some points on a map.
So I have a "to" and "from" object per trip, I've created a MapPoint entity with latitude, longitude and location name attributes. On my Trip entity, I've added a "to" and a "from" relationship who's destination is MapPoint.
But what do I do with the inverse property?
Because Xcode seems to give a warning it I leave it as "No inverse".
I needed to create 2 relationships on MapPoint to reference back to the Trip to the "to" and another relationship referencing the "from" relationship of Trip.
Is this correct ? I can't quite understand.
I have a similar issue with a User Entity where this is being used in several other Entities, should I be implementing an inverse relationship back to each Entity which uses User?
To keep Xcode happy it seems I need to create a relationship on User back to Trip, and back to other Entities I'm using such as an Upload, Picture entities etc... it seems to me disturbing to think a Trip has a User object, which would then have prepared to link back to an Upload/Photo... which has nothing to do with that Trip.
If you want to support inverse relationships for your to and from relationships, you can just add appropriate relationships to your MapPoint entity. Call them tripTo and tripFrom, or whatever seems appropriate to you, and set those as the inverse relationships for your to and from relationships, respectively.
As the docs explain, you're not required to model a relationship in both directions, but doing so makes life easier. What happens, for example, when a user is deleted? If you have a number of other entities related to User, then you need some way to figure out which objects were related to that user so that you can update them. If you have inverse relationships, Core Data can automatically update any related objects using the deletion rule (like nullify) that you choose. Without inverse relationships, it's up to you to fix up any related objects.
I'm not entirely familiar with Core Data, but I believe it has a form of entity inheritance.
You could make your MapPoint entity abstract and create a FromMapPoint and a ToMapPoint which inherit their attributes from the MapPoint entity.
Your Trip entity can then have two separate relationships - one to FromMapPoint and one to ToMapPoint with the appropriate inverses.
As I said - I'm no CD expert, so hopefully someone else can come along and validate/shoot-down this suggestion?
With a bit of digging I found that you can set the parent entity through the Data Model Inspector. I created this quick representation of what you've been talking about.
In my experience Core Data doesn't "require" you to have inverse relationships, but not having them leads to mysterious bugs, even if you make sure to keep your object graph consistent manually. At least I think that's what was causing the mysterious bugs.
The SQLite store uses inverse relationships to represent to-many relationships. For a to-many relationship foo from entity A to entity B, I would have thought it would create a separate table "foo" with a column A and a column B, with object ids appearing more than once in column A. Nope. It doesn't represent one-to-many relationships at all, it represents their inverses only, which are to-one relationships. It represents fooInverse as a column in entity B's table, containing object ids that correspond to A-type entities. So you must have an inverse. It seems that in simple cases Core Data can deduce what the inverse should be if you don't define it, and your to-many property works correctly. However in more complicated cases such as the one you describe, it falls over.
I am trying to use Core Data to represent a sports league's schedule. Within my model I have an entity called Team and an entity called Game. Each team will have many games. Each game will have two teams, one that is identified as the home team and the other that is identified as the away team.
In my current approach I have defined "homeTeam" and "awayTeam" relationships within the Game entity. Each of those relationships are to-one and have their destinations set to the Team entity. I have also defined a to-many "games" relationship within the Team entity that has its destination set to the Game entity.
The problem with this approach is that I can't set the inverse relationships in any appropriate way. It would require the Team/games relationship to be the inverse of both the Game/homeTeam and the Game/awayTeam relationships, and that isn't allowed (as far as I can tell). I could of course define these as unidirectional relationships but I start getting Xcode warnings and I'm not sure that's a good thing to do here.
I've also considered removing the awayTeam and the homeTeam relationships from the Game entity and replacing it with a teams relationship. That relationship would be many-to-many with Team, with a min and max value of 2. However, the approach doesn't allow me to distinguish between the home team and the away team, which I will need to do in my app.
I'd appreciate any recommendations for the best way to represent these kind of relationships within CoreData. I could no doubt implement this myself using my own DB layer, but I'd rather rely on CoreData than come up with a home-grown solution here.
Here is how I would do it:
Game has two one-to-one relationships, homeTeam and guestTeam.
Team has two one-to-many-relationships, homeGames and outGames. The inverse of homeGames is homeTeam, and the inverse of outGames is guestTeam.
Makes sense?
I have two entities: patient and checkpoint.
Patient has attributes such as DOB, name, ID, etc.
Checkpoint has attributes such as dateRecorded, height, weight, etc.
You probably get the idea- I want there to be a set of patients, and then each patient can have checkpoints associated with that patient.
On both entities, how should I set the settings? The settings are:
I looked at the documentation for this, and I was still confused. I think what I want is a one to many relationship (for patient), but then I'm not sure how to set the inverses for either of them, or the delete rule and the other stuff. THANK YOU!!
I just got started with Core Data this week. Great question!
Relationships:
Since one patient can have many checkpoints, the Patient to Checkpoint relationship is a One to Many relationship. The concept of an "inverse relationship" is essentially this: You've got a relationship going one way (Patient to Checkpoint) - now go ahead and look at it from the inverse, the Checkpoint's perspective. A checkpoint can apply to only a single patient. Therefore, the Checkpoint to Patient relationship is a One to One relationship.
Inverse Relationships:
To handle the inverse relationship, simply create each relationship, ignoring the inverse. Then, after you have the relationship on each object, go ahead and define the inverse as the relationship on the other entity.
In other words, a relationship points to another entity or a group of entities. An inverse relationship points to a relationship on another entity.
Delete Rules:
As far as delete rules are concerned, it's fairly simple. When trying to delete a patient which has checkpoints...
Deny: Core Data won't let you delete the Patient.
Cascade: Core Data will delete the Entity (Patient), as well as cascading through relationships and deleting those objects as well. (In other words, Core Data will delete the Checkpoint objects too.)
Nullify: Core Data will delete the patient but first remove the relationship. The Checkpoint will remain intact.
For the Patient entity might want either deny or cascade, depending on how you want to manage your data. Based on your usage case, you probably don't want nullify, since Checkpoints are dependent upon Patient entities.
You want nullify for the Checkpoint, since the Cascade would prevent you from deleting a checkpoint without deleting the entire patient, and Deny would effectively force the same.
Based on the scenario mentinoed, it looks like a one to many relationship between patient and checkpoint tables.
Now add a relationship from “Patient” to “Checkpoint”, and also set the inverse between the tables.
Also, set the delete rule for both relationships to “cascade”. This means that if you delete one object with Patient, the corressponding Coredata will delete the associated object as well.