Let's say I had one entity called "Garage" and one entity called "Cars".
In SQL I might create a third table (sometimes called a glue table) that would just have two fields "GarageID" "CarID"
That way I could relate certain cars to certain garages.
How would this be handled with the Core Data modeller?
Thanks!
You are talking about many-to-many relations. CoreData supports such model. Just create in both entities relations to each other set as "to-many". That's all.
Related
I have a very centralized table "RecordInfo" which holds some general data
e.g.: UserModified, UserCreated, DateTimeCreated, etc.
This table should be accessible via a navigation property from any other table in my application. Therefore I'm using a GUID Column to join the tables.
So it acts similar an one-to-one relation, but I cannot make a Foreign Key to multiple target tables. This will not work due to the FK constraints.
So I'm searching for a solution to implement navigation properties, without defining a ForeignKey - is this possible in any way?
From what I learned in school many years ago, an entity is an actual object in a database. A recordset or a dataset.
This is how I remember it but I may be wrong.
But in many books I read an entity is not an object but the data model, like a class, for the object. When I am in the Core Data - Data Model Editor in Xcode and I click on "Add Entity" I don't add an object to the database but another data model.
So I am confused!
An entity, is it like an object, or like a class I can create objects from?
If you want to become proficient in core data you should learn the associated vocabulary which admittedly might be counter-intuitive at first.
Let me stress that core data is not just a database wrapper but an object graph. Therefore, please take the equivalencies I give here with a grain of salt.
An entity would correspond to a table in a database.
An attribute would correspond to the particular fields in a table.
A relationship (to-one or to-many) would be the presence of a foreign key.
A many-to-many relationship would be a join table with two foreign keys.
One "record" in a database would be an instance of a certain entity.
Note that it is common practice to model entities with corresponding classes which are subclasses of NSManagedObject. Thus instantiation works pretty much like with any other object, only that they are persisted in the database store.
Definitely spend some time on the Core Data Programming Guide.
I am trying to use the Entity Mapping Model to migrate my existing many-to-many relationships in my application. I have the following relationships
Teams <<----->> Players
A Team entity can have multiple players, and a Player can be part of several teams. Now, I am trying to split this relationships to one to many by introducing a new entity with the following properties
TeamToPlayer
Team *team
Player *player
So the new relationship will look like
Team <--->> TeamToPlayer
Player <-->> TeamToPlayer
I am trying to figure what kind of entity mapping should be I be using to transform my core data model. Is it possible to do the above using the Mapping model or do i need to write code by inheriting NSMigrationPolicy class.
Any thoughts would be very helpful.
Thanks,
Javid
After trying to understand the migration process and entity mapping models for couple of days, I finally managed to find a solution. I was surprised to find how simple it was.
I created two entity mapping with Source from Player & Team to TeamToPlayer and mapped the relationships from the source entity to the destination entity relationship.
And updated the relationship mapping names in the PlayerToPlayer and TeamToTeam relationship mapping to use the new entity mappings.
Everything just worked.
I'm very new to the core data programming. I understand that the entities are tables, and I'd like to do the following:
One table, "Record" has an attribute "recordID" in another table ("Event") I have a series of events associated with this record, they all also have an attribute "recordID". There's a one entry in the "Record" table to many "Events" relationship between these tables, linked by "recordID".
I would like to know how to use the GUI "Fetched Properties" in the Data Model Editor to retrieve an array of "event" for the record's current recordID.
I checked the predicate programming guide, and it mentions that I can do something like this:
[NSPredicate predicateWithFormat:#"anAttribute == %#", [NSNumber numberWithBool:aBool]];
So in the GUI, I was thinking of using
recordID == recordID
How do I differentiate between different tables ? do I say self.recordID = recordID or something?
Edit:
Unless I completely misunderstand what the relationships are for. Do relationships automatically link tables for me?
First, Core Data is not a database. Core Data is an object graph that can persist to a sqlite file.
Second, Core Data handles the relationships for you. Just create a relationship between the two entities, set the Record instances as the "parent" to the Event instance and the relationship will be created for you.
You do not need to create foreign keys yourself. Core Data will manage them and keep the referential integrity for you.
Core data is not a database and so I am getting confused as to how to create, manage or even implement Lookup tables in core data.
Here is a specific example that relates to my project.
Staff (1) -> (Many) Talents (1)
The talents table consists of:
TalentSkillName (String)
TalentSkillLevel (int)
But I do not want to keep entering the TalentSkillName, so I want to put this information into another, separate table/entity.
But as Core Data is not really a database, I'm getting confused as to what the relationships should look like, or even if Lookup tables should even be stored in core data.
One solution I'm thinking of is to use a PLIST of all the TalentSkillNames and then in the Talents entity simply have a numeric value which points to the PLIST version.
Thanks.
I've added a diagram which I believe is what you're meant to do, but I am unsure if this is correct.
I'd suggest that you have a third entity, Skill. This can have a one to many relationship with Talent, which then just has the level as an attribute.
Effectively, this means you are modelling a many-to-many relationship between Staff and Talent through the Skill entity. Logically, that seems to fit with the situation you're describing.