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.
Related
I'm currently trying to create a CMS that allows users to edit Text Areas and Images in a PDF that allows them to move, scale, and change element z-indexes (bring in front, bring to back).
What's the best way to map out a database to consider for Z indexs.
I'm using Entity Framework Code First for this process.
If you are using Code First, then you shouldn't worry about mapping out the database - EF is going to do that for you.
I'd suggest creating POCO's (plain old CLR objects) to represent each of your entities (Text Areas, Images). Then, add a property to each object for "Z index". I mean, it sounds like each object can have 1 and only 1 z-index, right?
Hope that helps. Scott Gu has a nice intro/tutorial:
http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx
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.
I am working on an iPhone app and have an entity set up in coredata that has two attributes
text
order
The user can take a photo for each object in the entity. As a proof of concept, I am saving the photo using the entites 'text' attribute in the documents folder.
I tried getting the object ID using: [object objectID], but that gives me a string full of guff, eg:
<x-coredata://791282FC-9A08-451F-9348-1B972E8A144D/Articulation/p5>
My idea was to add another attribute 'id' to the entity that autoincrements and use that id as the filename of the photo (there will only ever be one photo per entity).
Is that considered bad practice? And if so, what should I be doing?
Thanks,
James.
I would create an attribute imageFileName in the entity, and store the file name of the image there.
That way, you can implement what you want to do now (by autogenerating imageFileName by incrementing an internal counter),
or you can let the user name the image, if you later change your mind.
It is non-trivial to change the CoreData schema once you ship your app. So I prefer to keep a bit of room in the schema so that I can change the behavior of the program without changing the schema.
This is a good question. I'd consider creating some sort of uniqueId property that you can use to identify the object as well as generate filenames etc.
Here's a link with a previous question that can point you in the right diretion: https://stackoverflow.com/questions/3005688/how-to-auto-increment-reference-number-persistently-when-nsmanagedobjects-created
I have a one to many relationship between two objects, lets call them Gallery and Images.
Each Image belongs to a Gallery and each Gallery has many Images.
I would like to add a fetched property to my Gallery model which would return one and only one Image object.
Is there a way to do this with fetched properties?
For a fetched property, a predicate is your only option.
See the Predicate Programming Guide - Aggregate Operations section. You'll want to use array[FIRST].
Note, you'll likely get a different image each time, since there is no support for ordered sets in Core Data. You'd normally get around this by maintaining your Images' sort order in a "sortOrder" key and setting sort descriptors on your fetch, but I don't think it's possible to give sort descriptors on a fetched property.
Update for Lion: Support for ordered sets has been added to Core Data in 10.7 and above, making an extra "sortOrder" attribute unnecessary for apps targeting 10.7 and up.
A fetched property is represented by the NSFetchedPropertyDescription class. You can modify properties in code up until the point when the managed object model is actually used. So, in the code that loads up your managed object model, you can find your fetched property description and replace the fetch request with something that better matches what you're trying to do. You should be able to set a fetch limit on it in this way.
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)