WinAPI UuidToString: 6eac0df7-46d2-11eb-8287-2c44fdb89adb
Firebird gstat: 0DF76EAC-46D2-11EB-8782-442CB8FDDB9A
Firebird UUID_TO_CHAR: F70DAC6E-D246-EB11-8287-2C44FDB89ADB

Забавный зоопарк.
Posted via ActualForum NNTP Server 1.5

hvladMON$GUID {D60E1149-EB9E-415D-C3BE-4035451D3C9D}

Вот поэтому хотя бы fb_info_db_guid стоило отдавать в честном двоичном виде...
Posted via ActualForum NNTP Server 1.5

dimitrНо нафига, если во всех остальных местах оно юзается как строки.

А я в FireSwarm собираюсь использовать БД UID как часть глобального идентификатора
транзакции везде, включая хранилище и сетевой протокол. Поэтому хочется его иметь размером
в 16 байт, а не 36. Придётся копипастить код из движка и надеяться, что вам и дальше будет
лень этот зоопарк вычищать.
Posted via ActualForum NNTP Server 1.5

dimitrPR бы лучше замутил, чем многослойные грабли строить...

На ещё один info item?..
Posted via ActualForum NNTP Server 1.5

dimitrна замену GUID_LEGACY_FORMAT на GUID_NEW_FORMAT внутри Guid* функций (и выкидывание
GUID_LEGACY_FORMAT к чертовой бабушке). Или я слишком категоричен? ГУИДы у нас через бекап
не передаются, так что проблем с совместимостью быть не должно вроде.

Там, видишь ли, проблема несколько более комплексная, чем преобразование. По уму надо бы
перепахивать всё, начиная с генерации. Потому что есть такой RFC 4122, который
специфицирует платформо-зависимый двоичный формат UUID и его преобразование в строку. В
первом посте первая строчка - как раз по этому RFC.

И хотя генерация-то UUID в Firebird этому RFC соответствует (по крайней мере на Windows),
но вот его преобразование - нет. Ни старое, ни новое.

Ещё одна проблема: база-то у нас подразумевается платформо-независимая, а в заголовке у
неё - внезапно! - платформо-зависимый UUID.

И если всё это разруливать, то PR получится опять неприемлемо большим и много чего ломающим.
Posted via ActualForum NNTP Server 1.5

dimitrНо в плане преобразования правильно работают только CHAR_TO_UUID и UUID_TO_CHAR. Ты в них
заглядывал?

Заглядывал. evlUuidToChar:


То есть тупо выводится 128-ми разрядное число в big endian. Это соответствует тому, что
написано на вики, но не RFC. Хотя я не прослеживал всю цепочку. Возможно, байты где-то тасуются уже после того, как их выдал вызов CoCreateGuid() в guid.cpp.

PS: Нашёл, они тасуются в evlGenUuid, но все прочие места (включая DB UID) используют
результат GenerateGuid "как есть".
Posted via ActualForum NNTP Server 1.5

PPS: Хотя вывод и идёт как big endian, GenUuid тасует байты так, что time-часть идёт
первыми байтами, что совсем нехорошо для индексов.
Posted via ActualForum NNTP Server 1.5

kdvПравда, с тех пор вроде CreateClassID стало возвращать guid в более правильном порядке.

Идентификаторы классов это вообще левая вещь, тянущаяся с тёмных веков. Правильные
генераторы это UuidCreateSequential() и UuidCreate().

[quot kdv#22255039Казалось бы, если у вас 36 "случайных" символов, ну сделайте порядок групп нормально сортируемым, что за проблема...[/quot]
Мелкая такая проблема: они вообще не предназначались для сравнений на больше-меньше, только на равенство.

dimitrТут правда фигня в том, что оный порядок байт есть только на винде, а на линуксе просто
поток случайных байт.

Это сейчас в Firebird реализовано так, а вообще-то есть
https://linux.die.net/man/3/libuuid например...

dimitrв общем смысле это выглядит довольно бессмысленной затеей.

Без специального типа, торчащего наружу - да.
Posted via ActualForum NNTP Server 1.5

Dimitry SibiryakovНашёл, они тасуются в evlGenUuid

Да, с перетасовкой вывод соответствует RFC:

MS = {5b2c1ba0-48fc-11eb-8287-2c44fdb89adb}
ODBC = {5B2C1BA0-48FC-11EB-8287-2C44FDB89ADB}
gstat = {1BA05B2C-48FC-11EB-8782-442CB8FDDB9A}
UUID_TO_CHAR = {5B2C1BA0-48FC-11EB-8287-2C44FDB89ADB}

Но менять сейчас эту перетасовку для пущей дружелюбности к индексам, наверное, уже поздно...