> Le 14 janv. 2017 à 11:41, Daryle Walker <dary...@mac.com> a écrit : > > >> On Jan 11, 2017, at 3:58 PM, Keary Suska <cocoa-...@esoteritech.com> wrote: >> >> >>> On Jan 11, 2017, at 11:16 AM, Jens Alfke <j...@mooseyard.com> wrote: >>> >>> >>>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel <mail...@xenonium.com> wrote: >>>> >>>> UUID means Universally unique identifier and it must be unique: >>>> https://en.wikipedia.org/wiki/UUID >>>> <https://en.wikipedia.org/wiki/UUID><https://en.wikipedia.org/wiki/UUID >>>> <https://en.wikipedia.org/wiki/UUID>> >>>> To generate an UUID, use a standard system function (CFUUID, NSUUID, >>>> libuuid, …) >>> >>> This is not what I believe Daryle was asking, and it’s sent everyone off on >>> a tangent about what UUIDs are. >>> >>> My interpretation of the original question: Is an NSIncrementalStore’s UUID >>> scoped to the specific database, or is it scoped to that _implementation_ >>> of the store? That is, is the UUID generated at runtime or at compile time? >>> >>> I don’t know the answer; just hoping to get the discussion back on track :) >> >> The docs say: >> "A unique identifier for the store at the given URL. It must be >> uniquely and reproducibly derivable, such that multiple instances of your >> store return the same UUID” >> >> My reading is that the store UUID would be unique to a specific database >> since it is only unique to the URL location of the store. I thin the docs >> use “instance” in a strictly OOP sense. > > Yes, this is what my question is about. Could I grab a UUID from a > get-a-random-UUID site,
You don’t need a get a random UUID site to get an uuid. Open your terminal and type uuidgen. > hard code it as a type-level property in Swift, and use it for every > instantiation (even for different files)? If this isn’t acceptable, 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. > > 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? Your storage should have metadata and contains the UUID. Each time you create a new database, you should generate a new UUID and store it in your storage metadata. If your storage don’t support that (that's unfortunate for a storage format that is supposed to support storing any type of data, as in practice you can always create a internal table to store them), maybe the best you can do is attach the metadata to the file directly using extended attributes for instance. Extended attribute may be lost by some operation, but it should be relatively stable as long as the file does not leave the machine. _______________________________________________ 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
