Re: Core Data: Changing Transient Keys Dirties Database?
Re: Core Data: Changing Transient Keys Dirties Database?
- Subject: Re: Core Data: Changing Transient Keys Dirties Database?
- From: mmalcolm crawford <email@hidden>
- Date: Wed, 22 Jun 2005 10:07:28 -0700
On Jun 21, 2005, at 9:51 PM, Robert McNally wrote:
However, I also have another periodic task that changes my
application's idea of the "current date" every minute or so-- some
of my model objects observe this key and propagate some changes
through non-persistent keys of their own as a result. This action
should not, but does dirty the database, and causes the first
periodic task to rewrite the entire data store when it's not
necessary.
Umm, changing a transient property does not "dirty the database". It
adds undo events to the undo manager and marks the managed object as
updated.
The point of a transient property is precisely that, although it's
not stored in the persistent store, Core Data does track changes and
register undo events for the property...
<http://developer.apple.com/documentation/Cocoa/Reference/
CoreData_ObjC/Classes/NSPropertyDescription.html#//apple_ref/doc/uid/
TP30001178-BAJHJGHJ>
Finally, I notice that this seems to have something to do with the
Undo machinery, because I am able to perform an "undo" immediately
after the minute-timer fires, and if I perform that Undo, then the
database is no longer dirty. I tried surrounding my willChange/
didChange calls
Umm, what willChange/didChange calls...
One of my model objects has a number of keys that are either in the
model marked as "transient", or aren't in the xcdatamodel file at
all but my class has getters and setters for them. These getters
and setters either directly or indirectly call
"willChangeValueForKey/didChangeValueForKey," but they do not
directly nor indirectly update any of the persistent attributes.
... are you invoking the change notification methods outside the
scope described in "Managed Object Accessor Methods" (<http://
developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/
cdAccessorMethods.html#//apple_ref/doc/uid/TP40002154>)?
with [myUndoManager disableUndoRegistration/
enableUndoRegistration], but that only seems to make the ability to
perform the Undo go away-- the database is still dirtied.
You'll probably also need to invoke processPendingChanges, but it's
difficult to say more without knowing exactly what you're doing and why.
To address other aspects:
However, I also have another periodic task that changes my
application's idea of the "current date" every minute or so-- some
of my model objects observe this key and propagate some changes
through non-persistent keys of their own as a result.
It's not clear that model objects should be observing something in
the application. You should probably be sending messages to the
model objects from a controller.
Is there any reason that the non-persistent keys must be transient?
Can they be simple instance variables? What role do they play?
mmalc
_______________________________________________
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