@serg
Good day again)

Do I understand correctly that you release new versions every few months and this fix will not get into version 10.11.5, but will appear or example, in version 10.11.6?

Or have there been cases when, after a few days / weeks, an already released version was fixed?)

There have been cases. If a released version is basically impossible to use, like, some bug in packaging that our testing missed. But luckily it doesn't happen very often. Normally, indeed, this bug won't be fixed until the next release about 3 months from now.

@serg Good day, saw the status of release 10.11.6 scheduled for 2023-10-26, will this bug fix be included in this release?)

I cannot say for sure yet. There are few bugs I have to fix first before getting to this one. I hope it will be, though

@serg Maybe you can delay the release a little so that this bugfix is included in it? Waiting another 3 months for the next release would be a disaster

xpun, I've trying to understand how to define a comparison of two UUID values, how to determine what is "correct".

In your test case you compare

select id, model_value from t1 where id < '0189f81c-c795-71d0-bc3f-8b7b74abe044' order by id desc;

select id, model_value from t1 where concat(id) < '0189f81c-c795-71d0-bc3f-8b7b74abe044' order by id desc;

and get different results. But on itself it doesn't mean the comparison is incorrect. Compare with

create table t1 (a int);

insert t1 values (1),(8),(11),(18);

select * from t1 where a > '5' order by a desc;

a

18

11

8

select * from t1 where concat(a) > '5' order by a desc;

a

8

In other words, comparing values as strings and using the native type comparison can produce different results, it's not a bug.

How can I see that the comparison is incorrect?

@serg
Let's give an example of how I use uuid in real production.
I'm using uuid as a replacement for unsigned integer auto-increment id. I use the "uuid" type because it only takes 16 bytes instead of char(36) and I can generate "uuid v7" from backend and know id of the insert row before i make insert query to mariadb.

For example, I'm creating a table with "messages (id, user_id). Both columns has "uuid" type.
Uuid v7 - monotonically increasing, so I insert step-by-step message and got 100 messages in this table.

First I want to retrive 20 latest messages. Then the next 20, and so on.
My first query:

select id, user_id from messages where user_id = "example_uuid" order by id desc limit 20

.

Next query:

select id, user_id from messages where user_id = "example_uuid" and id < "uuid_from_first_query" order by id desc limit 20

In version 10.11.4, when using uuid v1, it worked like that. I expect uuid v7 to behave the same as uuid v1.

Uuid v7 was invented to monotonically increase as a replacement for regular autoincrement. And it's expected to sort essentially like a number. Otherwise if I need a simple random string I can generate uuid v4.

Uuid v1 - also monotonically increasing, but it is more prone to collisions

It seems you're right, the latest UUID draft (from 20 October 2023) says

UUIDv6 and UUIDv7 are designed so that implementations that require sorting (e.g., database indexes) sort as opaque raw bytes, without need for parsing or introspection.

Old draft said the same. That is, indeed, concat(uuid) and uuid should sort the same way, at least for v6 and v7.

By the way, note that UUIDv1 — as generated inside MariaDB — isn't prone to collisions, MariaDB guarantees that all UUID() values are unique, even if requested within the same 100 ns time slot.

serg,
https://github.com/MariaDB/server/commit/caa033a6c786c6e2503d0489a4437ba4bb8fb85a is ok to push.
Can you please add comments to these methods:

+  static bool mem_need_swap(const char *s)

+  { return s[6] > 0 && s[6] < 0x60 && s[8] & 0x80; }

+

+  static bool rec_need_swap(const char *s)

+  { return s[6] & -s[8] & 0x80; }

.

.. which part of the above two expressions checks what.