• 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
Core Data : Synchronizing objects with SQLite file
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Core Data : Synchronizing objects with SQLite file


  • Subject: Core Data : Synchronizing objects with SQLite file
  • From: Jerry Krinock <email@hidden>
  • Date: Fri, 07 Feb 2014 13:58:37 -0800

I’m currently running a Core Data app in Xcode and trying to figure out why an object tells me that the value of its ‘foo’ attribute is nil, but when I query the SQLite file on disk, the value of the ‘ZFOO’ attribute for the problem object is a short string, not nil.

There is only one managed object context with this store, and it was created on the main thread.  The value of ‘foo’ was pre-existing in the store when the app launched and should not have been changed.  The app gives me three indications that foo is nil…

• app’s user interface indicates that foo is nil.
• Using lldb’s expr command, [problemObject foo] returns nil
• Creating a fetch request in lldb, sending -[NSManagedObjectContext executeFetchRequest:error:] returns descriptions of the data for 4 objects as expected; all look good except that the problem object has foo=nil.

I’ve also tried in lldb:

• -[NSManagedObjectContext save:]
• -[NSManagedObjectContext refreshObject:problemObject mergeChanges:YES]
• -[NSManagedObjectContext processPendingChanges]

All methods executed OK but did not change any of the results.

Executing an ‘update’ query with another program upon the SQLite file, I changed a different attribute of the problem object.  Upon re-executing the fetch request in lldb, the problem object was now a fault.  I then sent [myObject foo], which still returned nil, but this apparently caused the data to be “faulted in”, because a subsequent fetch request in lldb no longer showed a fault, but now showed all of the old data.  That is, foo=nil still, and the different attribute was still at its old value.

Do I misunderstand how this stuff is supposed to work?

Thanks,

Jerry


_______________________________________________

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


  • Follow-Ups:
    • Re: Core Data : Synchronizing objects with SQLite file
      • From: Fritz Anderson <email@hidden>
  • Prev by Date: Re: NSToolbar delegate -toolbarAllowedItemIdentifiers not getting called, other delegate methods are
  • Next by Date: Re: NSToolbar delegate -toolbarAllowedItemIdentifiers:
  • Previous by thread: Re: NSToolbar delegate -toolbarAllowedItemIdentifiers:
  • Next by thread: Re: Core Data : Synchronizing objects with SQLite file
  • Index(es):
    • Date
    • Thread