Re: On NSIncrementalStore UUID Uniqueness
Re: On NSIncrementalStore UUID Uniqueness
- Subject: Re: On NSIncrementalStore UUID Uniqueness
- From: Alastair Houghton <email@hidden>
- Date: Mon, 16 Jan 2017 08:59:31 +0000
On 14 Jan 2017, at 10:41, Daryle Walker <email@hidden> wrote:
>
> Could I base the UUID off a hash of the URL? Maybe, but it wouldn’t survive file moves. There are file references in macOS, which would be more stable, but I read that there’s a bug in the URL class where it would degrade file-reference URLs to standard-file URLs, so that’ll be problematic. Another solution would to create bookmark data from a file URL and take a hash of that. But are multiple bookmark data blocks of the same file URL consistent enough for this idea to work?
FYI, you can base a UUID off any identifier you please, so if you have *any* stable identifier, you can use that. The way you do so is:
1. Generate a UUID for your namespace, if there isn’t a standard one. (Standard ones exist for domain names, URLs, OIDs and X.500 DNs. Otherwise just generate a version 1 or 4 UUID, as appropriate.)
2. Use that and your identifier to compute an SHA-1 hash.
3. Use the SHA-1 hash to generate a version 5 UUID.
I think you mentioned e-mail as an example; well, if you’re using Core Data to hold a mailbox, you could regard the user’s e-mail address as a stable identifier for that purpose, in which case you can use that to generate a UUID.
> On 16 Jan 2017, at 01:50, Daryle Walker <email@hidden> wrote:
>
> 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.
It seems not unlikely that Core Data might be upset/confused if for any reason you had two separate sets of data open in the same process and the persistent store had the same UUID for both. That might happen if you were doing some kind of migration or copy between two of your data files, no?
Personally, if I was going to use Core Data, I’d make my “file" a bundle rather than a flat file anyway, which makes it easy to store a UUID (and indeed other metadata) in it. That also has the advantage that any large objects you need to save can be referred to by reference from the Core Data store, as opposed to being embedded in it, which is likely to be more efficient in almost all cases.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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