Re: On NSIncrementalStore UUID Uniqueness
Re: On NSIncrementalStore UUID Uniqueness
- Subject: Re: On NSIncrementalStore UUID Uniqueness
- From: Daryle Walker <email@hidden>
- Date: Sun, 15 Jan 2017 20:50:51 -0500
> On Jan 14, 2017, at 2:32 PM, Jens Alfke <email@hidden> wrote:
>
>
>> On Jan 14, 2017, at 2:41 AM, Daryle Walker <email@hidden <mailto:email@hidden>> wrote:
>>
>> I’m seemingly stuck since the data format doesn’t have a UUID field within it and I can’t base a UUID off of a hash of the file since it would change after each edit.
>
> There’s really no way to store any custom metadata in the file? I assume it’s some sort of database-like file (since it can be used to store CoreData objects), so couldn’t you create an extra record and store a UUID in it?
No, my file format is straight-up dumb data.
I’ve read for years that Core Data can support custom storage formats. Looking into it, I see that there are caveats. My first thought experiment, e-mail messages, was stymied by each non-primitive data block needing to have a database-ish ID. My second thought experiment, mbox files, is now stymied that the file as a whole needs a database-ish ID too. (Since mbox files can be multi-gigabyte, I’d make their loading read-only, letting me use each record’s byte offset as the base for an ID.) These IDs need to be consistently derivable; randomly-generated IDs are no good.
If I continue this idea, I’ll stick in a constant UUID and hope Core Data doesn’t really need universally-unique IDs for all potential stores.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
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