Re: Checking integrity of a Core Data document with SQLite store
Re: Checking integrity of a Core Data document with SQLite store
- Subject: Re: Checking integrity of a Core Data document with SQLite store
- From: Dave Fernandes <email@hidden>
- Date: Thu, 18 Mar 2010 01:04:36 -0400
Thanks, Ben and mmalc for the responses.
I found that prefetching the commonly accessed objects in my document's initWithContentsOfURL:ofType:error method finds the corruption pretty reliably. Hopefully, this is a reasonably robust check without being as i/o intensive as an integrity check.
It would be nice, though, to have a method that I was sure provided good coverage of the physical file.
Dave
On 2010-03-15, at 11:03 PM, Ben Trumbull wrote:
>
> On Mar 15, 2010, at 7:49 PM, Dave Fernandes wrote:
>
>>
>> On 2010-03-15, at 3:30 PM, Ben Trumbull wrote:
>>
>>> Running an integrity check can be useful if you have previously gotten a corrupt db error back from fetching or saving, or your app previously crashed, or you have some other active indicator it might be worthwhile. However, it's quiet expensive in I/O and you should not do it on every app launch / document open. Customers with account home directories on AFP, NFS or SMB servers will be very unhappy, and if your files become large enough so will people using local drives.
>>
>> That's a shame. It would certainly be easier to check when opening the file than to scatter code all over the app to diagnose the problem. Is there a standard exception I can expect to get when fetching or saving? NSInternalInconsistencyException is the one I currently get.
>
> You should generally get an NSError with the code that is NSFileReadCorruptFileError. In gdb, what does:
>
> >future-break objc_exception_throw
> >future-break +[NSError errorWithDomain:code:userInfo:]
>
> ...
>
> >info threads
> >thread apply all bt
>
> say ?
>
> The only place you should get an exception is if you try to fault in an object that is unreachable. Either because the database was deleted or corrupted, or because another thread / context deleted that object you wanted before you and you only held the reference instead of getting all the data at once (e.g. race on delete)
>
> - Ben
>
_______________________________________________
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