Re: Core Data : Searching using transient attributes as criteria
Re: Core Data : Searching using transient attributes as criteria
- Subject: Re: Core Data : Searching using transient attributes as criteria
- From: Eric Morand <email@hidden>
- Date: Mon, 5 Jun 2006 11:11:56 +0200
Le 5 juin 06 à 10:50, Chris Hanson a écrit :
On Jun 5, 2006, at 1:31 AM, Eric Morand wrote:
I suppose I have to stop using transient properties, they seem
less an less useful to me every new day (they mark the database as
dirty when they are modified BUT they can't be used in predicates;
they are part of the database on one side, but not on the other
side).
Your statement above is a little imprecise. In Core Data, it
doesn't make sense to say anything can "mark the database as
dirty." Neither is it the case that transient properties "can't be
used in predicates."
Manipulating a transient property of a managed object will mark the
managed object context it is associated with as having unsaved
changes. This is quite different than "the database" — by which I
suspect you mean "the persistent store" — a managed object context
is a scratchpad. You might not care that it has unsaved changes.
You might care that it has unsaved changes because you might be
converting your transient attribute to a persistent representation
when the managed object is sent -willSave. Or, you might wish to
undo your changes; transient properties fully support undo.
It is problematic because changing a transient attribute sets the
close button of a document window to "unsaved changes" (the dark dot
in the center of the button). It does'nt make sense to me. Imagine
you have a transient attribute that compute the balance of a bank
account when the account if "awakeFromFetch". Well, in this case,
when the app is started and the list of accounts is displayed, the
window is immediatly set to "unsaved changes" state ! Pretty
confusing for a user that haven't even started to use the application
- he has just launched it and it already has "unsaved changes" ? How
could he understand that ?
Transient properties are also fully supported in predicates,
generally speaking. That is, if you have an array of managed
objects that have a transient property, you can filter that array
using a predicate. Similarly, you can evaluate a predicate that
references a transient property directly against an object just
fine. What you can't do is execute a fetch request that references
a transient property. The reason is that getting the actual value
of a transient property requires instantiating a managed object;
otherwise, how is the managed object context supposed to know what
the actual value of the transient property should be?
If you think about it in this way, the restrictions on how
transient properties can be used make quite a bit of sense. And
even given these restrictions, they're extremely useful.
Well, I'm pretty sure they are useful for a lot of cases. But in my
case, I only use transient attributes to compute account balance and
it is useless if the user can't even create a smart group based on
the balance of its accounts.
I suppose I just have to not set the balance as transient if I want
to achieve what I need, though.
Anyway, thanks for your help, both of you. I learn each time I use
this mailing list. :o)
Eric. _______________________________________________
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