On 14 Jan 2017, at 10:41, Daryle Walker <dary...@mac.com> 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 <dary...@mac.com> 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 (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
