On 7 Feb 2014, at 3:58 PM, Jerry Krinock <je...@ieee.org> 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
