On 2008 Nov, 28, at 12:15, Markus Schneider wrote:
thanks for your advice. I will go with the relationships model.
Well, one more thing, and this is directed to others, not you Markus.
In a project I am working on, I too have an managed object Foo with a
property that is a set in my case a set of of strings. I have two
choices for modelling this property:
* model the set of strings directly as an attribute, of type
transformable
or
* model the set of strings as a a to-many relationship of 'bars' to
an entity Bar of class NSString.
The, latter, the "elegant" choice, does have a disadvantage when I
want to make a copy/insert a Foo from one managed object context into
a different managed object context.
If it's an attribute, it simply gets copied with all the other
attributes when I enumerate over -[NSEntityDescription
attributesByName].
But if it's a to-many relationship, I need to write and maintain
additional code in my -copy method. This additional code must
enumerate over the bars of the foo, copy/insert new Bars and wire up
the relationships.
So, I would say that the choice is indeed worth considering in each
application. Modelling as a to-many relationship is not always better
than modelling as an transformable attribute.
_______________________________________________
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]
