On 28/06/2012 14:02, Paul Vinkenoog wrote:
> People, this thread (from Dec 2011) was never properly concluded.
>
>>> On Thu, 15 Dec 2011 15:14:20 -0200, Adriano dos Santos Fernandes
>>> <adrian...@gmail.com> wrote:
>>>> There is no UUID "binary representation" in the RFC. There it's just a
>>>> formated string.
>>> Yes there is a binary representation defined in
>>> http://www.ietf.org/rfc/rfc4122.txt in section 4.1.2. It also explicitly
>>> says that bytes should be in network byte order (aka big-endian).
>> Thanks!
>>
>> So indeed we're generating invalid binary representation currently, due
>> to the endian issue.
> That's right, the problem is in GEN_UUID, not in the conversion functions.
>
>
Thanks for catch this up. I believe you're correct, like I was too, but
fooled on all the noise of this thread.
------------------------
All,
CORE-3238 is the problem related to UUIDs version and reserved bytes
which we're not respecting.
Note that in Windows, we generate UUIDs with a WinAPI function so it
generates correct numbers, but in POSIX we just generate random data.
1) So from a POV, we may say our GEN_UUID is correct in Windows only,
and that UUID_TO_CHAR (and CHAR_TO_UUID) are always incorrect, since
they don't put each reserved byte in the correct text representation place.
In this POV, we may need to change POSIX GEN_UUID and introduce new
functions for TO/FROM CHAR.
2) I'd instead would consider another way. I'd say current GEN_UUID is
always wrong, and just change it for all platforms.
The new version will translate the Windows GUID differently, so the
reserved bytes would be in the right place for FROM/TO CHAR functions
work correctly.
In this way we also maintain the below property, where the string
representation matches the octet one:
execute block returns (
o varchar(16) character set octets,
c varchar(36)
)
as
begin
o = gen_uuid();
c = uuid_to_char(o);
suspend;
end!
------------------------
To complicate it all up, this discussion happened before CORE-2898 fix
(which fixed the little-endian behavior).
So just to be sure:
- Octets and string representation of a UUID should visually match, as
currently it does.
- GEN_UUID was always wrong, not only under POSIX or big-endian.
- Since new GEN_UUID should return a correct visual representation of
the in-memory struct, and uuid_to_char already just convert it
byte-by-byte to string, new conversions functions are not necessary.
- GEN_UUID result should not be treated in the client as a in-memory
GUID directly. It *was* correct for this provided that server and client
were little-endian, but this "property" will be lost.
- Case for UUID_TO_CHAR will not be changed as this will be backward
incompatible. So we live with it, everyone could use LOWER.
Also I guess there is still time to commit it for 2.5.2, as otherwise
nothing of this makes sense.
Adriano
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
