On Mon, Nov 24, 2008 at 6:23 AM, Paul Tomlin <[EMAIL PROTECTED]> wrote: > > > I would create a separate Entity in your model and then define a to-many > relationship from your "Person" to that new Entity, possibly called > something like "PersonAttribute". The new Entity may have, for example, > Attributes for name and value. You then have something close to a normal SQL > joined table > > If you want strongly typed attributes then you can create a hierarchy based > on an abstract PersonAttribute, the 'sub entities' having string/float/int > "values". That's a model I've used successfully in my short experience with > CD. >
Thanks for the response, it has validated my approach. I'm still unsure how to query such a structure in a way that would say return an NSArray so that I could put the data into a table with bindings. I'd create the column and bindings programatically, but the transposition of the attributes from "vertical" key value pairs into a horizontal. In SQL, this would be relatively simple with a Join per attribute. I'm back again to the limitation imposed by Core Data that only a single entity can be queried. I'm envisioning a wrapper layer to perform my queries, but if I'm forced to go down that road, I'll more or less have to do everything from scratch, so it kind of nulls out the benefits that Core Data brings. Have I really missed something, or is this just one of the "Walls" that Core Data imposes. -- Colm _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
