>
> 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 perfectly agree with this point : since these smart groups
are
common to all my documents, they should not be stored in the
database. But I hate to have to do the same work twice and
if I use a
layer of abstraction, I have to (I'll have two sorts -
classes - of
smart goups : one only used for the "common"
groups, and the other
for the custom groups which are stored in the database).
That's why I was thinking about using the already perfectly
working
smart groups NSManagedObject subclass, create them at
run-time and
store them in a "in memory store".
_______________________________________________
Do not post admin requests to the list. They will be
ignored.
Cocoa-dev mailing list (Cocoa-dev lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-de
v/bond%40yahoo.com
This email sent to bondyahoo.com
|