• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreData: Using willSave to update timestamps causes hang?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData: Using willSave to update timestamps causes hang?


  • Subject: Re: CoreData: Using willSave to update timestamps causes hang?
  • From: Jim Correia <email@hidden>
  • Date: Tue, 3 May 2005 13:06:30 -0400

On May 2, 2005, at 3:59 PM, mmalcolm crawford wrote:

-willSave isn't really designed for making user-visible changes in this way. I'll file a bug report for that; please file an enhancement request (use the feedback button) for the clarification in the documentation.

mmalc,

Thanks for your help.

The documentation enhancement/clarification request is <rdar://4106260>.

Is there a recommended way for keeping a last saved date attached to individual entities then? The last saved date may or may not be displayed in the UI at any given time.

If I change the requirements to be the last edit time, I suppose I could catch the edits via a setValue:forKey override and make sure the key isn't the timestamp key (and that we aren't in the middle of an undo or redo.) Are there gotchas with this approach? Bad idea?

Anyone doing something similar?

I'd recommend against use of didSave in the way you suggest(*). A better architecture would be to register for the relevant save notifications and refault the objects...

I've uploaded a new sample project...

<http://homepage.mac.com/jimcorreia/tmp/WillSave.zip>

By re-faulting, do you mean

- (void)managedObjectContextDidSave:(NSNotification *)notification
{
NSArray *updated = [[notification userInfo] objectForKey: NSUpdatedObjectsKey];
NSEnumerator *enumerator = [updated objectEnumerator];
NSManagedObjectContext *context = [self managedObjectContext];
NSManagedObject *object = nil;


    while (nil != (object = [enumerator nextObject]))
    {
        [context refreshObject: object mergeChanges: NO];
    }
}

This causes the UI to refresh, but I still end up with a phantom undo state. (Is there a good bottleneck to set a breakpoint so I can watch CoreData register undos, and do/undo them to understand what is going on when I encounter a "phantom" undo state?)

Thanks,
Jim


_______________________________________________ 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
References: 
 >CoreData: Using willSave to update timestamps causes hang? (From: Jim Correia <email@hidden>)
 >Re: CoreData: Using willSave to update timestamps causes hang? (From: mmalcolm crawford <email@hidden>)
 >Re: CoreData: Using willSave to update timestamps causes hang? (From: Jim Correia <email@hidden>)
 >Re: CoreData: Using willSave to update timestamps causes hang? (From: mmalcolm crawford <email@hidden>)

  • Prev by Date: Re: OutlineEdit example (_NSArrayControllerTreeNode)
  • Next by Date: Re: How to get the time and date format from user prefs
  • Previous by thread: Re: CoreData: Using willSave to update timestamps causes hang?
  • Next by thread: Re: [OT] Submitting app listing to Apple's product site
  • Index(es):
    • Date
    • Thread