Re: How do you store an NSArray as an attribute in a Core Data entity
Re: How do you store an NSArray as an attribute in a Core Data entity
- Subject: Re: How do you store an NSArray as an attribute in a Core Data entity
- From: email@hidden
- Date: Fri, 20 Mar 2009 05:45:48 -0400
On Mar 19, 2009, at 1:26 AM, email@hidden wrote:
>> I want to store a list of Strings as an attribute of an entity in
>> Core Data but there doesn't appear to be a way to use NSArray (or
>> NSSet or NSDictionary either) as an attribute.?Please can someone
>> explain how you use an NSArray or NSDictionary as an attribute of a
>> Core Data entity?
> In general, if you want to have multiple things as an attribute of a
> Core Data entity, what you really want is a to-many relationship with
> another entity.
> Let's take tags as an example. Say I'm creating a weblog editor and I
> want the ability to tag my posts. I could model this as a string
> attribute with some specific format (space- or comma-separated), or as
> a transformed attribute. However, that doesn't get me the ability to
> do things like say "show all the posts with this tag" or even "auto-
> complete known tags." It also leads to persistent store bloat because
> I'm breaking a cardinal rule of relational data, "store each piece of
> data once," because each tagged post winds up with a copy of the tag's
> text.
> Instead of having an attribute, I would model a to-many relationship
> from my Post entity to my new Tag entity, with a to-many inverse
> relationship from my Tag entity to my BlogPost entity. This way:
> Each Tag instance only exists once in the persistent store.
> I can traverse the object graph between Posts and Tags, and between
> Tags and Posts, with ease.
> I can perform interesting queries across both Posts and Tags to
> improve my user experience (e.g. support auto-completion or generate
> tag clouds).
> Not having Tags stored directly on Posts means if I'm just dealing
> with a Post, Core Data won't bother fetching the Tags too.
>
> Entities and relationships are good, hope this helps you leverage them!
>
> -- Chris
Hello Chris,
Thank you for your prompt help. As you say a one-to-many relationship is indicated in?
your example and indeed is what I am after for a similar application to your example.?
In Core Data though you can only use entities in relationships so you can't directly use?
NSString or other foundation objects in a relationship property. My thinking was that it?
seems pointless to create an entity which contains a string rather than using a NSString directly.
However thinking further I believe I read that an instance of NSManagedObject basically?
looks up the fields for the entity that is is representing in the corresponding NSEntityDescription?
then just uses KVC for those properties, so I guess an entity with a single string instance variable?
is a thin wrapper anyway. So Apple's design here makes sense.
Another poster has suggested using transformable attributes which probably works because?
the default value transformer transforms objects that are NSCoding compliant according to the?
Core Data programming guide, which NSArray and NSString are. I should have read this more carefully.
Thank you for clarifying for me.
Regards,
Tim Mowlem
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden