Optimized for databases

• The first 36 bits are dedicated to the Unix Timestamp: seconds since 1st January 1970 (unixts)
• The next 12 bits are dedicated to providing sub-second encoding for the Nanosecond precision (nsec).
• The next 4 bits are dedicated to the version (ver).
• The next 18 bits are dedicated to providing sub-second encoding for the Nanosecond precision (nsec).
• The next 8 bits are dedicated a monotonic clock sequence counter (seq).
• The last 50 bits are filled out with random data to pad the length and provide uniqueness (rand).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            unixts                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|unixts |         nsec          |  ver  |         nsec          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     nsec  |      seq      |               rand                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             rand                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This version is the same as the v1 but it does not contain seq bits. The lack of monotonic clock sequence allows generation without a generator.

• The first 36 bits are dedicated to the Unix Timestamp: seconds since 1st January 1970 (unixts)
• The next 12 bits are dedicated to providing sub-second encoding for the Nanosecond precision (nsec).
• The next 4 bits are dedicated to the version (ver).
• The next 18 bits are dedicated to providing sub-second encoding for the Nanosecond precision (nsec).
• The last 58 bits are filled out with random data to pad the length and provide uniqueness (rand).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            unixts                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|unixts |         nsec          |  ver  |         nsec          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     nsec  |                       rand                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             rand                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This module also exports some utility functions for working with LUUID.

• add_hyphens
• remove_hyphens
• parse
• to_bytes
• from_bytes

In FirebirdSQL, LUUID can be stored just like any UUID, using the type BINARY(16).

FirebirdSQL provides functions to transform UUID from BINARY(16) TO CHAR(36) (UUID_TO_CHAR()) and the other way around (CHAR_TO_UUID()). These functions work correctly with LUUID.

This library provides the utility functions to_bytes and from_bytes.

• to_bytes transforms a luuid string into a []u8
• from_bytes transforms a luuid []u8 to a string With these you can bind and retrieve []u8 to and from BINARY(16) columns. No more SELECT UUID_TO_CHAR(...) and INSERT CHAR_TO_UUID(...) in your queries.