Core Data: Changing Transient Keys Dirties Database?
Core Data: Changing Transient Keys Dirties Database?
- Subject: Core Data: Changing Transient Keys Dirties Database?
- From: Robert McNally <email@hidden>
- Date: Tue, 21 Jun 2005 21:51:47 -0700
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.
What I'm trying to achieve is a "smart" commit that only re-writes the data store if persistent attributes of model objects have changed. I have a periodic task that checks to see whether [myManagedObjectContext hasChanges] is true, and if so, does a [myManagedObjectContext save].
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.
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 with [myUndoManager disableUndoRegistration/enableUndoRegistration], but that only seems to make the ability to perform the Undo go away-- the database is still dirtied.
What is the correct way to deal with this kind of situation?
Thanks,
Robert
_______________________________________________
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