Re: Core Data : Synchronizing objects with SQLite file
On 2014 Feb 10, at 12:01, Fritz Anderson wrote: > Am I correct that you routinely use your Core Data store as a straight SQLite > database? Not just peeking with a browser or the sqlite3 command line? Thank you, Fritz. No, generally I only peek into the SQLite file for troubleshooting. The problem, which was that there was some confusion between migrated versions of the file, and possibly an SQLite tool I was using (not sqlite3 command-line) was lying to me. Anyhow, the fetches agree with what is in the file now. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Synchronizing objects with SQLite file
On 7 Feb 2014, at 3:58 PM, Jerry Krinock wrote: > 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? Am I correct that you routinely use your Core Data store as a straight SQLite database? Not just peeking with a browser or the sqlite3 command line? If I do understand you correctly, that’s a “voids your warranty” situation. The Core Data schema is proprietary, and accessing it directly may have… unanticipated effects, no matter how confident you are in your reverse-engineering. My strategy (off the top of my head): 1. Work out a way not to use SQLite directly. 2. Write a command-line tool that recovers your data, one way or another. 3. Write it to a clean CD store. 4. Serve and enjoy. — F ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data : Synchronizing objects with SQLite file
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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
