Here's how I'm doing it in an app I'm writing:
I have an abstract entity called AbstractGroup, which has a string
attribute called "name", a number attribute called "weight", and a
method stub that returns an NSSet * called "items".
AbstractGroup has two subclasses: AbstractSmartGroup and Group. A
Group adds nothing except a many to many relationship to my Item
entity. AbstractSmartGroup adds a string attribute called "predicate".
AbstractSmartGroup has two subclasses: DefaultGroup (has a string
identifier; this would be like a Library or a Recent Items folder,
etc; something the user can't change), and SmartGroup.
When I want all the items in an AbstractGroup, I ask it for its items
array. If it's a Group, it gives me the items as defined by its
relationship. If its an AbstractSmartGroup subclass, it creates a
fetch request based on its predicate, executes it on its
managedObjectContext, and returns the results as a set.
The predicate I keep as a string, because NSPredicates are initialized
with strings.
This might not be the best way to model it, but it works for my
needs. :)
HTH,
Dave
On May 30, 2009, at 8:14 AM, Ulai Beekam wrote:
How would you model "smart playlists" (like in iTunes) with Core Data?
If you have a Song entity, it is fairly obvious how you model a
"regular playlist". The RegularPlaylist entity would simply have a
to-many relationship to the Song entity, being a simple collection
of songs that the user adds to and removes from at will.
But what about "smart playlists"? What attributes/relationships
should the SmartPlaylist entity have? In my user interface I would
probably have a NSPredicateEditor to make a predicate to filter the
results. So shouldn't SmartPlaylist at least have a "predicate"
attribute (of type binary data)? And what about the list of songs
itself? Should it be a fetched relationship? If yes, the question
arises how and when I should update it, since fetched relationships
are not "dynamic", as they say in the Core Data doc.
Thanks, U.
_______________________________________________
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 arch...@mail-archive.com
