Re: Temporary object created at runtime with Core Data
Re: Temporary object created at runtime with Core Data
- Subject: Re: Temporary object created at runtime with Core Data
- From: "I. Savant" <email@hidden>
- Date: Tue, 25 Apr 2006 09:38:08 -0400
If all you're worried about is whether or not you should have a
single instance of an entity in your context, don't. You can either
abstract like I suggested before (which you don't like), or go ahead
and create/store the 'fixed' smart groups when your document is created.
I successfully use this approach in several projects. Consider (in
your persistent document):
- (id)librarySmartGroup
{
// Check private ivar to see if it's set (like _librarySmartGroup)
// If not ...
// Try to fetch "the" library smart group
// If none available, create and insert one
// Assign the fetched or inserted one to the ivar for caching
// Return the ivar
}
If there's ever the possibility of another smart group being
manually inserted (such as a user editing an XML file), you will need
to think about a "verification" process to make sure there's still
only ever one per document.
I may be totally missing the point of your question, however, so
forgive me if this doesn't apply. I *do* think, however, in the case
of an iTunes-like "smart group" scenario, my original suggestion
(adding a layer of abstraction) is still the better way to go because
you don't have to store things that are common to *all* of your
documents. I mean, depending on the selection, you can still easily
get to that group's predicate, whether fixed or customizable ...
--
I.S.
On Apr 25, 2006, at 9:19 AM, Eric Morand wrote:
I understand your idea and this is what I'm currently using. :o)
But I don't like it. Because myy smart groups have everything
needed to fetch some datas and I consider that a "Podcasts only"
source is nothing more than a smart group. I don't want to have to
design another custom class for that kind of sources because my
smart groups are exactly what I need.
_______________________________________________
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