Support for CHAR(16) CHARACTER SET OCTETS

[Fr0sT]

Well some things are ready.
Those who are interested can check current process here: https://github.com/Fr0sT-Brutal/Zeos_dev/tree/tmp_Guids and play with test app.

Done:
- Query domain info when receiving metadata
- Set Guid type to metadata column by type (Char(16)) or domain name
- Read/write Guid values
- Set Guid type to fetched column by type (Char(16)) or domain name
- Set Guid type to SP parameters

To do:
- Set Guid type by field names (?)
--- Dataset-level: will require additional objects (field lists) and code
--- DB-level with table prefixes: will require parsing and additional checking
- Set Guid type to SP result fields - hard to do because Zeos won't query metadata for SP result set...

Note that internally FB operates big-endian GUIDS while Zeos utils (as well as RTL's) only deal with little-endian ones. So user should not mix GUIDS created by FB server and by client machine.

[Fr0sT]

Mostly done here https://github.com/Fr0sT-Brutal/Zeos_de ... esting-7.3

Additionally done:
- Set Guid type by field names (DS-level option)
- Set Guid type to SP result fields - by type or by field names

Changes will be committed to SVN as soon as SF ends their long-lasting disfunction period

[marsupilami]

Note that internally FB operates big-endian GUIDS while Zeos utils (as well as RTL's) only deal with little-endian ones. So user should not mix GUIDS created by FB server and by client machine.

Hello Fr0st,

maybe we should do a conversion here between big endian and little endian? Otherwise the ASCII representation of GUIDs will not be the same?

Best regards,

Jan

[Fr0sT]

maybe we should do a conversion here between big endian and little endian? Otherwise the ASCII representation of GUIDs will not be the same?

Well, we could. But is this difference really important? Server does no byte swapping, it's all about how it interprets the value. And this only affects string representation of GUID values used on server side.
There are two cases:
- string GUID input from SQL - we couldn't do anything here anyway
- string GUID output - but where could it be used? For logging to a file? Probably. But database could be connected with tons of other clients written on various languages so if we'll do some magic inside, the behavior of these clients will become inconsistent.

I've no specific opinion on this. I even met GUIDs 1st time just when I started implementing this request

[marsupilami]

Hello Fr0st,

yes - the difference can be important. One Example: The Microsoft Installer uses GUIDs to identify products. Assume you know that AC76BA86-1033-F400-7760-1000003D0004 is the GUID for Acrobat 9.0 Professional, English/French/German, volume license. It is - see https://www.adobe.com/devnet-docs/acrob ... ntify.html.

Assume we push this GUID into the inventory database for our computers with something like this: TField.AsGuid = StrToGuid('AC76BA86-1033-F400-7760-1000003D0004');

If you have to do a manual search, which value would you put into your search?
a) AC76BA861033F40077601000003D0004
b) 86BA76AC331000F477601000003D0004
c) something else?

This is only one example. Another example within the same realm would be to assume that you have software that imports GUIDs from textual files. This software is written using FPC and runs on INTEL (little endian) and MIPS (big endian) hardware. Without making sure that GUIDs are treated correctly, one will import the above guid as a different byte sequence than the other. The same goes for exporting: If you export an database generated GUID on two systems with different endianes, you will get different string representations in export files, if you don't convert between the database representation and the host representation.
Functions that convert between Network Byte order and Host Byte Order might come in handy here to write generic code because Network Byte order is Big Endian - the same Byte order that is used by Firebird for generating GUIDs.

Best regards,

Jan

[Fr0sT]

Hello Jan,

If you have to do a manual search, which value would you put into your search?
a) AC76BA861033F40077601000003D0004
b) 86BA76AC331000F477601000003D0004
c) something else?

What do you mean by "manual search" here? If SELECT GuidField FROM ... then there will be no problems as FB doesn't change GUID value. It will return byte chains just like they were added. Only SELECT UUID_TO_STR(GuidField) FROM ... will change things but converting data to string on server side is always a bad idea anyway.

Another example within the same realm would be to assume that you have software that imports GUIDs from textual files. This software is written using FPC and runs on INTEL (little endian) and MIPS (big endian) hardware. Without making sure that GUIDs are treated correctly, one will import the above guid as a different byte sequence than the other. The same goes for exporting: If you export an database generated GUID on two systems with different endianes, you will get different string representations in export files, if you don't convert between the database representation and the host representation.
Functions that convert between Network Byte order and Host Byte Order might come in handy here to write generic code because Network Byte order is Big Endian - the same Byte order that is used by Firebird for generating GUIDs.

Well, this case is totally client-side. Some IFDEF'ed endianness swapping should be added indeed (and it will require some thinking) but it's not FB fault.

[marsupilami]

Hello Fr0st,

I am sorry for my late answer. Currently there are family problems that I have to tend to. I didn't mean to say that anything is FBs fault or that there is a fault at all. All I say is that for Firebird I think we should convert between little endian GUIDs as they are used on Windows and big endian GUIDs as they are generated by Firebird. Otherwise we most probably will get bug reports about issues in the future because the conversion of binary GUIDs to strings will give different results on different platforms and in different environments which in turn would lead to problems in environments where GUIDs have a meaning besides just being a big random number. Environments where GUIDs have a meaning are the Adobe Reader product identifier and I think the same goes for Java. Other people might do similar things.

With best regards,

Jan

[Fr0sT]

Well, I doubt the endianness of the current platform could affect GUID to string conversion. Otherwise it is bug.

Actually I see no real cases where difference of GUID endianness could play role. Could you imagine a real, believable example? By real I mean those which are useful not theoretical cases like "GuidToString(Field.AsGuid) <> 'select UUID_TO_CHAR(GuidField)'"