vanbukin
commented
10 months ago Isn't Uuid.NewTimeBased more of a COMB GUID?
The short answer is - maybe.
The long answer - things are a bit more complex.
Initially, this package was developed to work with MySQL. This is because its behavior when working with System.Guid depends on the parameter of the connection string, which can have 7 (sic!) different values.
The main task I was solving is the creation of a structure that has
- identical string and binary representations
- an API that is similar to
System.Guid - performance not worse than that of
System.Guid
The generation algorithm is secondary and is not the main focus.
Technically, for MySQL, the value of the first 8 bytes is important. They need to form a monotonically increasing sequence. That's exactly why in the current implementation a unix timestamp is stored there, which ensures a monotonically increasing sequence.
And all this works because MySQL uses binary(16) to work with uuid. Therefore, we can generate a Uuid using the appropriate method (Uuid.NewTimeBased()), then call the ToByteArray() method, passing its result as a parameter in the query.
The situation is different with PostgreSQL.
PostgreSQL has a built-in data type for handling uuid (which is called - uuid), and its driver (Npgsql) does not allow out-of-the-box writing of a byte array there. Only System.Guid can be used.
At the same time, Npgsql relies on a specific layout of data within System.Guid.
For example, the code for generating a Uuidv7 might look approximately like this, packing its contents into a System.Guid, in such a way that Npgsql correctly conveys its value to PostgreSQL. Then, at the database level, it would look like a monotonically increasing sequence without time insertion drop-offs.
public static Guid Generate()
{
const ushort bits48To63ResetVersionMask = 0xFFF;
const ushort bits48To63SetVersionMask = 0x7000;
const byte bits64To71ResetVersionMask = 0x3F;
const byte bits64To71SetVersionMask = 0x80;
Span<Guid> guidBuffer = stackalloc Guid[1];
guidBuffer[0] = Guid.NewGuid();
var buffer = MemoryMarshal.AsBytes(guidBuffer);
var temp48To63 = (ushort) ((ushort) (BinaryPrimitives.ReadUInt16LittleEndian(buffer[6..]) & bits48To63ResetVersionMask) | bits48To63SetVersionMask);
buffer[8] = (byte) ((byte) (buffer[8] & bits64To71ResetVersionMask) | bits64To71SetVersionMask);
var unixTimeMilliseconds = (ulong) DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
BinaryPrimitives.WriteUInt64BigEndian(buffer, (unixTimeMilliseconds << 16) | temp48To63);
Span<byte> result = stackalloc byte[16];
result[0] = buffer[3];
result[1] = buffer[2];
result[2] = buffer[1];
result[3] = buffer[0];
result[4] = buffer[5];
result[5] = buffer[4];
result[6] = buffer[7];
result[7] = buffer[6];
result[8] = buffer[8];
result[9] = buffer[9];
result[10] = buffer[10];
result[11] = buffer[11];
result[12] = buffer[12];
result[13] = buffer[13];
result[14] = buffer[14];
result[15] = buffer[15];
var guid = Unsafe.As<byte, Guid>(ref result.GetPinnableReference());
return guid;
}Why this order? Because Npgsql reads
- int32 in little endian
- int16 in little endian
- int16 in little endian
- int64 in big endian
However, storing uuid as binary(16) with such an algorithm would lead to performance drops, while Uuid.NewMySqlOptimized() would not. In this case, you can write the uuid as a byte array (when the column has binary(16) type).
It seems
Uuid.NewTimeBasedrespects the structure of a UUIDv1 from RFC 4122 for the first 8 bytes (timestamp + version 1). The other 8 bytes are just randomly generated as in the case of a UUIDv4. As the clock sequence and node ID are missing, isn't this technically a variation of a COMB GUID? Instead of first 10 bytes of a UUIDv4 + 6 bytes of a timestamp (SQL Server specific), this is first 8 bytes of a UUIDv1 + last 8 bytes of a UUIDv4.I was expecting this to be like UuidCreateSequential, except the internal representation is big-endian.
See also RT.Comb.