CoreData - smart playlists? (was Re: Saving Images with Core Data (i.e., JPEG, TIFF, etc.))
CoreData - smart playlists? (was Re: Saving Images with Core Data (i.e., JPEG, TIFF, etc.))
- Subject: CoreData - smart playlists? (was Re: Saving Images with Core Data (i.e., JPEG, TIFF, etc.))
- From: Jim Correia <email@hidden>
- Date: Tue, 10 May 2005 13:11:33 -0400
On Apr 29, 2005, at 7:25 PM, mmalcolm crawford wrote:
Fetched properties are fetched lazily, then cached. If you want to
update the cache, then (as with other updates) you refault the object.
[...]
On the other hand, I am not sure I grok when I would use a fetched
property, as opposed to a stored fetch request. Is there an
implicit "must be in a relatioship with the entity that the
fetched property is a part of" condition on a fetched property, or
some such?
Think of how you might represent a smart playlists in iTunes. You
could use a fetch request in place of a fetched property, but this
requires a different (and "explicit") code structure -- that is,
you'll have to retrieve the fetch request from the model then
execute it. The fetched property specifies a relationship (albeit
a weak one). It's more natural to ask a (smart) Playlist for its
Tracks than to create and execute a fetch request for Track to
match a predicate. Moreover, you then have to maintain the set of
results yourself rather than it being associated with a particular
Playlist...
I hope these aren't naive newbie questions...
So how would you use a fetched property to represent something like a
smart playlist in iTunes? Can you specify a different predicate per
runtime instance for the "tracks" fetched property of the entity
SmartPlaylist?
Who, and what, should I observe in order to know when to refault the
object to update the lists of tracks?
(I suppose this question also applies to manual NSFetchRequests. At
some point the data will be stale, so who do I observe so I know to
trigger a re-fetch?)
Thanks,
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden