Re: How to keep creation/modification date of a (Core Data) object?
Re: How to keep creation/modification date of a (Core Data) object?
- Subject: Re: How to keep creation/modification date of a (Core Data) object?
- From: "Marcus S. Zarra" <email@hidden>
- Date: Tue, 17 Jul 2007 14:07:01 -0600
Have you considered adding the following (pseudo code) into your
awakeFrom[Fetch:|Insert:] methods?
get array of attributes from [self entity];
for each attribute {
add self as observer to the key
}
In the observer method:
update modification date
add modification date change to the undo stack
You could do this in a subclass of NSManaged object and you will have
the functionality automatically. When an undo is fired your
modification date would automatically be rolled back as part of the
undo. You would have to add a way to remove the observers but that
is simple enough.
This would avoid having to override -didChangeValueForKey: which Ben
already mentioned is a bad thing.
Marcus S. Zarra
Zarra Studios LLC
Simply Elegant Software for OS X
www.zarrastudios.com
On Jul 17, 2007, at 1:06 PM, Arthur C. wrote:
You should go back and (re)read Ben's post.
Okay, thanks. I missed that thread, which runs parallel to mine.
For completeness, the link:
<http://www.cocoabuilder.com/archive/message/cocoa/2007/7/15/186219>
-didChangeValueForKey: is going to be sent anytime a key changes
in pointer equality. This includes firing faults and undo. In
neither case should the modification date be bumped.
More specific, the modification date has to return to its old value
whenever a change is undone (well, you could argue about that, but
at least that would be compatible with Apple's choice. When you
edit a text file in TextEdit, and undo the changes, the file is
clean again, i.e. does not have to be saved).
To include correct behaviour on undo, the code is updated as follows:
- (void) didChangeValueForKey: (NSString *) thisKey
{
[super didChangeValueForKey: thisKey];
if( ( [thisKey isEqualToString:@"modificationDate"] == NO) &&
([self isFault] == NO) && ([[[self managedObjectContext]
undoManager] isUndoing] == NO) && (startUpFinished == YES))
{
[self setModificationDate: [NSDate date]];
}
}
Using [self setPrimitiveValue:[NSDate date]
forKey:@"modificationDate"]; as suggested by Ben, does not give
correct behaviour, as the modification date is not updated on
screen (no will/did change notifications, so the binding is not
triggered...).
The [self isFault] condition will not help me get rid of the
startUpFinished flag.
I'm currently using the most precise and most inconvenient method
of maintaining the modification dates.
Putting a setModificationDate call in every setter, yes... but that
was the reason I started this thread, to find a solution with
less / better code. It's surprisingly hard to implement this
(obvious) feature in a 'convenient' way...
Best regards,
Arthur C.
Jim
_________________________________________________________________
FREE pop-up blocking with the new Windows Live Toolbar - get it
now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
40zarrastudios.com
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden