Re: CoreData: get/set methods in undo and flushing of caches
Re: CoreData: get/set methods in undo and flushing of caches
- Subject: Re: CoreData: get/set methods in undo and flushing of caches
- From: Frank Illenberger <email@hidden>
- Date: Thu, 23 Jun 2005 16:56:08 +0200
Am 23.06.2005 um 16:47 schrieb John Timmer:
today I noticed, that the get and set methods in a subclass of
NSManagedObject are only called when I directly enter a value from
the bound NSTextField. They are not called again when I press the
undo button to restore earlier values. The problem now is: When the
set methods are called, they flush a certain cache that is connected
to the attribute. When the method is not called during an undo, I am
not able to correctly flush my cache. What would be the best pratice
to deal with this? Does every object of this class has to observe
itself to get a clue when to flush the cache?
This is a problem that I ran into as well. It seems that undo
mechanisms of
Core Data don't operate through the normal key/value coding methods
(ie -
the undo is not a symmetrical reversal of the do), so it's
difficult to tell
when a change gets undone. I'm thinking about filing it as an
enhancement
request, but I haven't gotten around to it.
I would advise against using key/value observing to handle this - I
had some
serious problems with crashes on undo when I was observing other
objects.
It seemed that the undoing left nil objects being observed when an
object
creation action was undone. You may do better observing self
rather than
observing another object - I'd be interested in hearing your
experience.
One useful thing that does occur on undoing is a
"NSManagedObjectContextObjectsDidChangeNotification" notification
gets sent
by the ManagedObjectContext. You can register for this, then look for
"self" in the changed objects set and rebuild the cache when
necessary.
Yes, I also tried to use this notification but the problem here is,
that you cannot tell from the notification which attribute was
changed in the last cycle. I have several attributes each with its
own cache and I cannot flush all caches just because one single
attribute changed.
I tried to compare against the snapshots, but these only reflect the
state of the last save and they do not reflect transient attributes.
The thing that currently works for me is to implement
didChangeValueForKey: in my subclass with a which is called during
undo. I first call super's implementation and then I do a string
comparison for the key. I then have an opportunity to flush my
caches. The downside here is, that it might decrease the performance
of the change notifications.
I think that caches are very much needed when implementing business
logic with CoreData. There should be a best practice for this.
Cheers
Frank
_______________________________________________
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