Re: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

> Le 19 janv. 2017 à 22:18, Daryle Walker  a écrit :
> 
> 
>> On Jan 16, 2017, at 12:08 PM, Charles Srstka  
>> wrote:
>> 
>>> On Jan 14, 2017, at 4:41 AM, Daryle Walker >> > 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?
>> 
>> The thing with file reference URLs degrading to file path URLs is in the 
>> Swift is actually not a bug, it’s deliberate 
>> (https://bugs.swift.org/browse/SR-2728 
>> ). The Swift team decided that file 
>> reference URLs are not appropriate for the Swift URL value type. However, if 
>> you’re using Objective-C, file reference URLs will still work fine, and you 
>> can always make an Objective-C wrapper that stores a file reference URL and 
>> use that from Swift.
> 
> I looked at some code that gives a workaround for the file-reference URL 
> problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit 
> values, then sprinkles those onto a URL string template. Since UUIDs are 
> 128-bit values, I could just copy a reference ID directly into a UUID.

The file reference URL content is an implementation details and relying on the 
fact that a reference ID is 128 bit is very fragile IMHO, especially as Apple 
is planning to introduce a new FS soon. On APFS they may decide to use 
something completely different for file reference.



___

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

Re: On NSIncrementalStore UUID Uniqueness

[Charles Srstka]

> On Jan 19, 2017, at 3:18 PM, Daryle Walker  wrote:
> 
> 
>> On Jan 16, 2017, at 12:08 PM, Charles Srstka > > wrote:
>> 
>>> On Jan 14, 2017, at 4:41 AM, Daryle Walker >> > 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?
>> 
>> The thing with file reference URLs degrading to file path URLs is in the 
>> Swift is actually not a bug, it’s deliberate 
>> (https://bugs.swift.org/browse/SR-2728 
>> ). The Swift team decided that file 
>> reference URLs are not appropriate for the Swift URL value type. However, if 
>> you’re using Objective-C, file reference URLs will still work fine, and you 
>> can always make an Objective-C wrapper that stores a file reference URL and 
>> use that from Swift.
> 
> I looked at some code that gives a workaround for the file-reference URL 
> problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit 
> values, then sprinkles those onto a URL string template. Since UUIDs are 
> 128-bit values, I could just copy a reference ID directly into a UUID. 
> However it means existing files would have a different style, possibly 
> overlapping, than new files (which would take a random UUID). Maybe it’ll be 
> better to always use a random UUID, the implementers do in practice.
> 
> — 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com 

That workaround relies on private implementation details, so I wouldn’t 
recommend it. I’d rather just wrap an NSURL within an Objective-C type and then 
call that from Swift (which is what I do in my code).

Charles

___

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

Re: On NSIncrementalStore UUID Uniqueness

[Charles Srstka]

> On Jan 16, 2017, at 12:48 PM, Quincey Morris 
>  wrote:
> 
> On Jan 16, 2017, at 09:08 , Charles Srstka  > wrote:
>> 
>> The thing with file reference URLs degrading to file path URLs is in the 
>> Swift is actually not a bug, it’s deliberate 
>> (https://bugs.swift.org/browse/SR-2728 
>> ). The Swift team decided that file 
>> reference URLs are not appropriate for the Swift URL value type.
> 
> Does the given justification make any sense to you? It certainly makes no 
> sense to me. Perhaps I’m missing something, but the discussion seems to me to 
> conflate the idea of a reference type in Swift with the concept of 
> “referencing” in the world in general:
> 
>> “The[y] are both technically a different type in spirit[**] and they 
>> actually behave much more like a reference type than a structure.”
> 
> 
> By analogy, this is like saying that the Swift String type is good for 
> representing people’s names, but that Obj-C NSString should be used for 
> representing [US] people’s social security numbers, because a SSN is more 
> like a reference than a value.
> 
> In fact, URLs *are* strings — URLs as defined by the RFC, I mean — and that 
> takes the semantics of relating the string to the resource that the string 
> locates outside the scope of the representation itself.
> 
> Perhaps the problem is that file reference URLs don’t have an eternal, unique 
> string representation — that storing and reconstituting a file reference URL 
> may produce a different string? In that case, it’s the URL (the value, not 
> the type) that’s broken, and it’s just as broken in Obj-C as Swift.
> 
> 
> ** Incidentally, they aren’t a different *type* in spirit. File URLs and file 
> reference URLs are both URLs: uniform [syntactically conformant with the RFC] 
> resource [file, in this case] locators [specifiers of where to find]. The 
> difference is in the semantics of the file system, which really has nothing 
> to do with the syntax of the URL.

This post from Apple clarified their reasoning a bit:

https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20161205/001052.html
 


Basically, they wanted to get rid of the optionality on many of URL’s 
properties; in Swift 2, .path was optional, .lastPathComponent was optional, 
and possibly some others as well. Apparently the only times those methods ever 
returned nil was when the URL in question was a file reference URL; in Swift 3, 
those methods are no longer optional, but file reference URLs are no longer 
supported. :-/

The part of the message that I find ominous is where he says “If references 
were still important”. When you start hearing language like that from Apple, 
it’s usually a sign that they consider the feature no longer relevant and soon 
to be axed. File references were always a key differentiator in the Mac user 
experience, and it would be very sad to see them go.

Charles

___

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

Re: On NSIncrementalStore UUID Uniqueness

[Daryle Walker]

> On Jan 16, 2017, at 12:08 PM, Charles Srstka  wrote:
> 
>> On Jan 14, 2017, at 4:41 AM, Daryle Walker > > 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?
> 
> The thing with file reference URLs degrading to file path URLs is in the 
> Swift is actually not a bug, it’s deliberate 
> (https://bugs.swift.org/browse/SR-2728 
> ). The Swift team decided that file 
> reference URLs are not appropriate for the Swift URL value type. However, if 
> you’re using Objective-C, file reference URLs will still work fine, and you 
> can always make an Objective-C wrapper that stores a file reference URL and 
> use that from Swift.

I looked at some code that gives a workaround for the file-reference URL 
problem. It grabs the reference ID as a 128-bit value, dumps it into 2 64-bit 
values, then sprinkles those onto a URL string template. Since UUIDs are 
128-bit values, I could just copy a reference ID directly into a UUID. However 
it means existing files would have a different style, possibly overlapping, 
than new files (which would take a random UUID). Maybe it’ll be better to 
always use a random UUID, the implementers do in practice.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___

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

Re: On NSIncrementalStore UUID Uniqueness

[Daryle Walker]

> On Jan 16, 2017, at 3:59 AM, Alastair Houghton  
> wrote:
> 
> On 14 Jan 2017, at 10:41, Daryle Walker  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 looked at NSIncrementalStore subclasses on GitHub for inspiration. (Couldn’t 
find any NSAtomicStore ones.) While in theory we should take at least 
semi-heroic measures, in practice everyone goes “screw it” and calls the random 
UUID function (from NSProcessInfo). One guy even hard-coded a “1” as the UUID!

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 


___

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

Re: On NSIncrementalStore UUID Uniqueness

[Quincey Morris]

On Jan 16, 2017, at 09:08 , Charles Srstka  wrote:
> 
> The thing with file reference URLs degrading to file path URLs is in the 
> Swift is actually not a bug, it’s deliberate 
> (https://bugs.swift.org/browse/SR-2728 
> ). The Swift team decided that file 
> reference URLs are not appropriate for the Swift URL value type.

Does the given justification make any sense to you? It certainly makes no sense 
to me. Perhaps I’m missing something, but the discussion seems to me to 
conflate the idea of a reference type in Swift with the concept of 
“referencing” in the world in general:

> “The[y] are both technically a different type in spirit[**] and they actually 
> behave much more like a reference type than a structure.”


By analogy, this is like saying that the Swift String type is good for 
representing people’s names, but that Obj-C NSString should be used for 
representing [US] people’s social security numbers, because a SSN is more like 
a reference than a value.

In fact, URLs *are* strings — URLs as defined by the RFC, I mean — and that 
takes the semantics of relating the string to the resource that the string 
locates outside the scope of the representation itself.

Perhaps the problem is that file reference URLs don’t have an eternal, unique 
string representation — that storing and reconstituting a file reference URL 
may produce a different string? In that case, it’s the URL (the value, not the 
type) that’s broken, and it’s just as broken in Obj-C as Swift.


** Incidentally, they aren’t a different *type* in spirit. File URLs and file 
reference URLs are both URLs: uniform [syntactically conformant with the RFC] 
resource [file, in this case] locators [specifiers of where to find]. The 
difference is in the semantics of the file system, which really has nothing to 
do with the syntax of the URL.

___

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

Re: On NSIncrementalStore UUID Uniqueness

[Charles Srstka]

> On Jan 14, 2017, at 4:41 AM, Daryle Walker  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?

The thing with file reference URLs degrading to file path URLs is in the Swift 
is actually not a bug, it’s deliberate (https://bugs.swift.org/browse/SR-2728 
). The Swift team decided that file 
reference URLs are not appropriate for the Swift URL value type. However, if 
you’re using Objective-C, file reference URLs will still work fine, and you can 
always make an Objective-C wrapper that stores a file reference URL and use 
that from Swift.

Charles

___

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

Re: On NSIncrementalStore UUID Uniqueness

[Alastair Houghton]

On 14 Jan 2017, at 10:41, Daryle Walker  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  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

Re: On NSIncrementalStore UUID Uniqueness

[Daryle Walker]

> On Jan 14, 2017, at 2:32 PM, Jens Alfke  wrote:
> 
> 
>> On Jan 14, 2017, at 2:41 AM, Daryle Walker > > 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 (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

Re: On NSIncrementalStore UUID Uniqueness

[Jens Alfke]

> On Jan 14, 2017, at 2:41 AM, Daryle Walker  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?

—Jens
___

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

Re: On NSIncrementalStore UUID Uniqueness

[Alex Zavatone]

On Jan 11, 2017, at 12:16 PM, Jens Alfke wrote:

> 
>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
>> 
>> UUID means Universally unique identifier and it must be unique: 
>> 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 :)
> 
> —Jens

Your conclusion seems to make the most sense.


___

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

Re: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

> Le 14 janv. 2017 à 11:41, Daryle Walker  a écrit :
> 
> 
>> On Jan 11, 2017, at 3:58 PM, Keary Suska  wrote:
>> 
>> 
>>> On Jan 11, 2017, at 11:16 AM, Jens Alfke  wrote:
>>> 
>>> 
 On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
 
 UUID means Universally unique identifier and it must be unique: 
 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

Re: On NSIncrementalStore UUID Uniqueness

[Daryle Walker]

> On Jan 11, 2017, at 3:58 PM, Keary Suska  wrote:
> 
> 
>> On Jan 11, 2017, at 11:16 AM, Jens Alfke  wrote:
>> 
>> 
>>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
>>> 
>>> UUID means Universally unique identifier and it must be unique: 
>>> 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, 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?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 


___

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

Re: On NSIncrementalStore UUID Uniqueness

[Keary Suska]

> On Jan 11, 2017, at 11:16 AM, Jens Alfke  wrote:
> 
> 
>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
>> 
>> UUID means Universally unique identifier and it must be unique: 
>> 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.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

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

Re: On NSIncrementalStore UUID Uniqueness

[Jens Alfke]

> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
> 
> UUID means Universally unique identifier and it must be unique: 
> 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 :)

—Jens
___

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

Re: On NSIncrementalStore UUID Uniqueness

[Alastair Houghton]

On 11 Jan 2017, at 00:16, Saagar Jha  wrote:
> 
> Small quibble: UUIDs are not guaranteed to be unique. It's just extremely 
> likely they will be, and they be sufficient for almost all applications, 
> including this one.

If we’re going to be pedantic, properly issued version 1 and 2 UUIDs *are* 
guaranteed to be unique - but that means (a) you have a properly issued MAC 
address that hasn’t been spoofed, and (b) you aren’t generating more than the 
rate limit for the UUID version (this should be prevented by the generating 
code; sometimes the generator has a lower rate limit because of the low 
precision of the system clock).  The downside is that version 1 and 2 UUIDs 
have privacy implications - they leak the MAC address of your device.  For some 
applications, though, this is not a problem and you may want to use a version 1 
UUID in that case.

Versions 3 and 5 are subject to hash collisions (MD5 and SHA-1 respectively), 
and version 4 (the one you should probably use as a sensible default) is random 
and so subject to statistical collisions.  It isn’t recommended to use version 
4 unless you have a source of high quality randomness available, to avoid 
collisions caused by poor quality random number generation (this won’t be a 
problem if you’re using the system APIs to generate them on Mac OS X or iOS).

Version 5 UUIDs can be useful if the thing you want to identify has e.g. a URL 
or FQDN or similar, as you can directly construct them from that, which might 
let you avoid e.g. another database lookup in some cases.  I would avoid 
version 3 (besides MD5 being weak to begin with, it’s also vulnerable to a 
length-extension attack; SHA-1 normally would be too, but in a version 5 UUID 
it isn’t because too many bits of the SHA-1 hash are missing... you’d need to 
try 275 billion different alternatives).

Also worth noting that different versions cannot collide with one another - 
there are version bits in the UUID.

TL;DR: Version 1 and 2 UUIDs should be unique.  Versions 3 through 5 can in 
most cases be assumed to be unique.

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

Re: On NSIncrementalStore UUID Uniqueness

[Saagar Jha]

Small quibble: UUIDs are not guaranteed to be unique. It's just extremely 
likely they will be, and they be sufficient for almost all applications, 
including this one.

Saagar Jha



> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
> 
> UUID means Universally unique identifier and it must be unique: 
> https://en.wikipedia.org/wiki/UUID 
> 
> To generate an UUID, use a standard system function (CFUUID, NSUUID, libuuid, 
> …)
> 
> 
>> Le 10 janv. 2017 à 11:36, Daryle Walker  a écrit :
>> 
>> Been reading up on NSIncrementalStore, including its guide. I think I grok 
>> it more now. When initializing an instance, you're supposed to submit an 
>> UUID. Can a single value be used for all instances, or is it supposed to 
>> unique per instance?  If the latter, and the source data doesn't already 
>> have a UUID field, do you to take heroic measures to ensure uniqueness? Or 
>> is a casual effort enough?
>> 
>> Sent from my iPhone
>> ___
>> 
>> 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/mailing%40xenonium.com
>> 
>> This email sent to mail...@xenonium.com
> 
> ___
> 
> 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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

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

Re: On NSIncrementalStore UUID Uniqueness

[Jean-Daniel]

UUID means Universally unique identifier and it must be unique: 
https://en.wikipedia.org/wiki/UUID 

To generate an UUID, use a standard system function (CFUUID, NSUUID, libuuid, …)


> Le 10 janv. 2017 à 11:36, Daryle Walker  a écrit :
> 
> Been reading up on NSIncrementalStore, including its guide. I think I grok it 
> more now. When initializing an instance, you're supposed to submit an UUID. 
> Can a single value be used for all instances, or is it supposed to unique per 
> instance?  If the latter, and the source data doesn't already have a UUID 
> field, do you to take heroic measures to ensure uniqueness? Or is a casual 
> effort enough?
> 
> Sent from my iPhone
> ___
> 
> 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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.com

___

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