Re the Core Data table below. I want to associate the "Color" entity with the "detailsColor" attribute (in the Details entity). The idea is that there are (in this case) three Colors applicable to detailsColor.
I would have thought the "Relationships" in Color would apply to the "detailsColor" attribute as these colors only apply there. I cannot seem to connect the two though. I can only create a relationship with the entire Details entity. Is this correct? Suggestions appreciated.
A relation connects entities, so it doesn't make sense to say that "colorDetails" applies "to the entire Details entity". Your set up looks okay to me.
Related
I have two tables - ContactInformation & EmailAddress - which have a many to many (* : *) relationship. After making this association in the ADO.NET data model and generate the db from it, a table titled ContactInformationEmailAddresses which maps the two tables is created in the Entities Container.
Unlike when I scaffold views which have a 1:* relationship, there's no entries available for its counterpart in the view when I scaffold either one and scaffolding off the combined table isn't an option even after updating the model from the db.
My question is simply: is there an automated way to generate the creation form for ContactInformationEmailAddresses that will have the EmailAddress entry field?
At present the scaffolding templates don’t support generating views that require the selection and association with more than one entity – the “many” end of the association.
Make sure to check out this blog article
http://blogs.msdn.com/b/mcsuksoldev/archive/2013/09/20/managing-entity-relationships-with-mvc-scaffolding.aspx
Relationships in Core Data just confuse me. I've read and read, but I just don't get it. I guess it doesn't help that I'm usually frustrated when reading. I want to do something really simple:
I have an Entity called Pictures and an Entity called User. I want Users to be able to like and tag other people in pictures, so each Picture entity has two relationships:
Picture Entity:
UsersWhoLikedThePicture (to-many):
Destination: User
Inverse: Picture
UsersWhoAreTaggedInThePicture (to-many):
Destination: User
Inverse: Picture
But this is causing so much mix up in use, that I can't even begin to describe. It's inconsistent. Someone likes a picture causes them to be removed as a tagged user, and like one picture causes your likes from all other pictures to be removed. Ahhh it's such a mess..does my structure look ok? How would I model this?
In addition to Matthias Bauch answer, I could give you some hints to understand relationships.
First, when you deal with Core Data you have to think in term of objects. By means of this astraction you could think at your model as a graph where nodes are the entities that you created in the model, while relationships are the links among those entities.
Now, about relationships, they could be of different types: one-to-one, one-to-many and many-to-many. Based on the type of relationships you have, you can create different link in the objects graph. For example, if a User has a to-many relationship with Picture, it means that each instance of object (of type NSManagedObject) has a link to different Pictures. User works as the source, Pictures, as the destination.
Inverse relationships are used by Core Data to maintain the graph consistency. In particular, they are useful when you deal with delete rules.
Each relationship has a delete rule associated with it. Cascade means that if you delete an object, say the User, Core Data will delete the object (the Pictures) linked to it for you. Deny doesn't allow to delete an User if there are Pictures linked to it. Nullify means the link from a Picture to a User will be broken. It doesn't mean that the objects are deleted. In terms of object graph, it means that you haven't anymore a link between those objects. No Action means that the source is deleted, the destination is always there and it continues to point to an object that doesn't exist anymore. So, unlike Nullify, you need to broke that link manually. If not you could have a graph inconsistency. Try to avoid this type of relationship.
If you want to know something else, let me know.
EDIT
Take a look at Core Data Programming Guide Relationships section for further info.
I don't know if this is even possible, but it sounds like you used the same inverse target for two relationships. Don't do that.
The right way would be something like this:
I am new with Core Data and I experiment a design problem.
Suppose I have two entities : "Product" and "Image".
The Image entity has an attribute named "type" ( normal, mini etc...).
I would like that the Product entity has attributes of type Image like : miniImageList, normalImageList etc... but I really don't know if it is possible given that with XCode4 graphical editor, it is not possible to create an attribute whose type is an entity previously declared.
The only ugly solution I found, is to create a to-many relation between Product and Image. Therefore, I have an NSSet generated which contains all the images I wish.The problem with this solution is that I need to test the type of the image I wish ( mini, normal ) etc... which is not really handy.
If any of you know how to solve this problem, you're really welcome ;)
Hope I've been clear, thank's for reading.
I would like that the Product entity has attributes of type Image like : miniImageList, normalImageList etc... but I really don't know if it is possible given that with XCode4 graphical editor, it is not possible to create an attribute whose type is an entity previously declared.
For that, you need to create relationships. An "attribute of type Image" is essentially a relationship between Product and Image.
A more appropriate solution in your case, would be to define fetched properties between Product and Image. Thus, miniImageList and normalImageList can be defined as fetched properties using the "filtering" you need to apply on your Images set. An important limitation of fetched properties though, is that they are not dynamic. You would need to ensure that the contents of the resulting Image NSArray take into consideration the latest Image entity additions/deletions/modifications.
Either seperate the different image sizes to entitys or you expand your Image entity to hold diferent sizes of the graphic.
Seccond method would be best in this case I think. An Product would have a easy to follow reference to the Image entinity and its properties.
Apple's documentation suggests the use of inverse relationships when modelling data models in CoreData.
I have the following example:
A Book (Entity) has several "pages" and one "frontCover" and one "backCover".
A Page (Entity) is in one "book" (so "book" is the inverse of "pages").
OK so far, that's the standard case...BUT now, my problem:
I only have one class Cover (Entity). A Cover (Entity) is on one "book". On this "book" the Cover is EITHER the "frontCover" OR the "backCover". So, the inverse of "book" is EITHER "frontCover" OR "backCover".
This cannot be modelled in CoreData. A relationship can only be the inverse of one relationship, but not of EITHER this OR that relationship.
What is the best way to model this? Unidirectional relationships (no invers)?
Thanks for your answers,
Chris
You could do something like the model below (first image). This would leaving of Cover's inverse relationships as nil. This doesn't feel right to me, though.
Another option (second image) would be to give Book a 'covers' relationship which references 2 Cover objects, and give Cover an isFront boolean attribute. This would allow for inverse relationship called 'book'.
One way to do it could be to create Cover as an "abstract" entity with two sub entities - FrontCover & BackCover. Then you could create the relationship & inverse to each of those.
I just want to add.
One way is to have 2 subentities. But that's useful only if FrontCover and BackCover differs a lot.
If they are exactly the same object, you should instead use an enum in the entities.
That enum differentiate whether the cover is frontCover or BackCover.
Then you set only 1 "to many" relationship from book to cover.
The purpose of coredata is to save your data. Your logic should be in the code anyway.
Also creating two subEntities is essensially the same with westSider's answer. Sub entities simply add another relationship on the original one.
I have objects:
type A (Id, Name),
type B (AId, Description).
I want to make relation 1-to-1 (and create it 1-to-[0..1]). All works great exept deleting objects of type A. When I'm trying to delete some object from type A exception occurs.
A relationship is being added or deleted from an AssociationSet ‘...’. With cardinality constraints, a corresponding ‘...’ must also be added or deleted.
Im searched for solution (found editing CSDL for many-to-many), but nothing helps. There is also cascade action defined in the table in Database.
Any suggestions?
UPD: Thanks for answers.
Let's say more clear.
I don't want to implement inheretance betwen A and B
I try to fix problem by editing edmx file (like this http://codepolice.net/2008/12/16/cascade-delete-in-entity-framework/), but no luck. Seems it's only worked for one-to-many.
I just want to have 2 objects with one-to-one relation. For example, Order and OrderDetails. I expected automatic creating/deleting OrderDetails for every Order I have.
1:1 should give an exception if your deleting B right?
I think what you want is 0..1
Right click Add->associations.
under multiplicity:
On the left hand side choose One for A and 0 or 1 on the right for B.
I think you need this if you want an optional description object(B) for A.
You could also move B's fields into A and check not null for those fields right? That might be easier, then I think you could just use A's fields.
Also, I'm not a database designer by a long shot but, wouldn't you want the Data of A in A?
If for instance you had "Person" and his "Home", I would think those would be a good case for 1:1 (or 0..1 real world), because they themselves are 2 distinct objects that other objects can share independently.
Seems like the A_DataObjects just leads to an unnecessary join?
Old Answer below (not looking for inheritance, but leaving for someone else):
OK, I think I ran into this today. I think what you might want to do is define 2 classes as subclasses of a base class (entity). Right click and do add -> inheritance to get started. I didn't get this all working yet, but I think it involves specifying a field in the base, BaseType which can be used to key in on the derived classes.
http://mosesofegypt.net/post/Inheritance-and-Associations-with-Entity-Framework-Part-1.aspx
Note, there's a part 2 and 3 of this.
-David
One way to do this is to have a single entity that maps to 2 tables. See:
http://msdn.microsoft.com/en-us/library/bb896233.aspx
Visual EntityFramework tool doesn't recognize correctly 'on delete cascade' and creates incomplete xml mapping. You have to change edmx file (You can do it with notepad). Instructions here:
http://codepolice.net/2008/12/16/cascade-delete-in-entity-framework/
Worked for me.
Just make a one-to-many relationship, then by creating unique constraints on the foreign keys in the database you can force it to be 1:1. You can find a full tutorial about it here
(This uses Code-First)