[10.x] Switch to UUID v7

[driesvints]

This will switch the default generated UUID's from v4 to v7 for Laravel v10. Since these are now sortable by default, orderedUuid has become an alias of uuid.

[DarkGhostHunter]

I think that Illuminate\Database\Eloquent\Concerns\HasUuid should call uuid() instead of orderedUuid() then.

[driesvints]

@DarkGhostHunter done, thanks.

[DarkGhostHunter]

@DarkGhostHunter done, thanks.

👌

[tillkruss]

@driesvints Should Str::uuid() stay version 4 (fully random) and Str::orderedUuid() switch to v7 (timestamp + random).

Otherwise all Str::uuid() will reveal the timestamp it was created at?

[driesvints]

Why would that be bad?

[DarkGhostHunter]

I don’t think that’s bad, but there is a case where both should be different. Some apps may need this to hide data that could lead to knowing usage. 

[tillkruss]

Why would that be bad?

It exposes data involuntary, just how incrementing integers expose how many database records (likely) exist, the UUID v6 as a default would expose the timestamp a record was created.

That's fine if we're talking about the ordered UUID for database records, since it's expected.

However when generating a UUID, I'd expect it to be fully random data.

[driesvints]

@tillkruss are you sure that's also the case with uuid v7? I'm also not sure what UUID v6 has to do here, we're not using that one.

[rodrigopedra]

@driesvints I guess so:

UUID v4:

Version 4 UUIDs are perhaps the most popular form of UUID. They are randomly-generated and do not contain any information about the time they are created or the machine that generated them.

reference: https://uuid.ramsey.dev/en/stable/rfc4122/version4.html

UUID v7:

Version 7 UUIDs combine random data (like version 4 UUIDs) with a timestamp (in milliseconds since the Unix Epoch, i.e., 1970-01-01 00:00:00 UTC) to create a monotonically increasing, sortable UUID that doesn’t have any privacy concerns, since it doesn’t include a MAC address.

reference: https://uuid.ramsey.dev/en/stable/rfc4122/version7.html

Although UUID v7 does not include any machine information, by being monotonic one can infer the order records were created, and probably the time it was created as the specification is based on Unix Epoch.

P.S. I believe @tillkruss reference to UUID v6 was a typo, and his meant v7. But only him can confirm that,

[tillkruss]

Yeah, sorry it was a typo, I meant v7.

[driesvints]

I think I'm a bit indifferent. I personally don't see the issue but maybe @taylorotwell has a different opinion.

[tillkruss]

I think I'm a bit indifferent.

Understandably, I opened a PR.

[SignetPlanet]

Not sure of the discussion but we use UUID v4 for tables with few writes but where the UUID needs to reveal as little information as possible. We use v7 for temporary tables or tables with high writes. Keeping v4 is good as it is still the recommended non-ordered UUID.

An important thing overlooked is sessions still use a 40 character string so they suffer from all the index performance issues that non-ordered uuids do plus they are stored in text fields creating indexes that are well over double the size and seriously underperforming. May want to have an option to have session IDs also be UUIDv7 as well and then it makes our sessions compatible with most load distributed systems.

[driesvints]

Hey @SignetPlanet. The former was resolved with #44311. For the latter you can always attempt a PR 👍

[dinandmentink]

I just noted the following:

Laravel v9's Str::orderedUuid() currently produces uuid v4 id's that, when sorted, would come after Laravel v10's Str::orderedUuid() based on uuid v7.

Example (at time of writing, obviously):

"v4 ordered: ". Str::orderedUuid() . " v7: " . Ramsey\Uuid\Uuid::uuid7()
"v4 ordered: 982878fe-158f-4b5c-9851-4b4ca5a4b8cb v7: 01858654-75f9-7316-b982-2e43994ec53d"

Note how the v4 ordered would come AFTER the v7 uuid.

Would this be an issue for the HasUuid trait after upgrading to v10? This would mean that primary keys would not be sorted correctly based on time of generation?

Maybe this was already thought of, but I noticed this in the middle of migrating my database to uuids and figured I would make sure this was flagged as I don't see it in the code or docs.

[driesvints]

Not sure. HasUuids uses v7 right now: #44311

[dinandmentink]

Yes. I have seen #44311. I'm referring to this issue including the the followup branch.

This is an upgrade issue I currently see when going from laravel v9 to laravel v10.

Given some model User using HasUuid.

1. User uses laravel v9 ordered uuids, based on uuid v4. (example: 982878fe-158f-4b5c-9851-4b4ca5a4b8cb)
2. Upgrade to laravel v10.
3. User will now receive v7 uuids (example: 01858654-75f9-7316-b982-2e43994ec53d)
4. Because v7 uuids use 0 padding for the most relevant bits HasUuid will now generate ids that will come BEFORE laravel v9's HasUuid.

I hope I'm making sense and getting this across, I do think there is an issue.

[driesvints]

@tillkruss do you have thoughts on the above? I guess for new apps it makes sense to use UUID v7? Should old apps overwrite to use the old UUID v4? Or should we completely revert all this?

[driesvints]

Hey all. We reverted all of the UUID v7 changes. Going forward, Laravel will keep using UUID v4 as a default and let users use UUID v7 manually if they like.

[SignetPlanet]

A config option to choose what generator to use for identifiers (UUID, ULID, or random strings) would be good, and have sessions also tie into that. The UUIDv7 take a small fraction of the time to generate vs the ordered UUIDv4 ones in Laravel.

…

On Fri, Jan 6, 2023, 7:21 a.m. Dries Vints ***@***.***> wrote: Hey all. We reverted all of the UUID v7 changes. Going forward, Laravel will keep using UUID v4 as a default and let users use UUID v7 manually if they like. — Reply to this email directly, view it on GitHub <#44210 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYE5QIEWJGZM5LGSU6J3UDWRAS5XANCNFSM6AAAAAAQQGLJTI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[driesvints]

We're not planning on a config option at this time. You can use Ramsey uuid or symfony one directly. You can overwrite the methods on HasUuids trait.

[SignetPlanet]

I currently use the HasUuid trait, which works fine for all tables except sessions. To do sessions with an UUID, I had to overwrite methods in I believe 4 different classes. Still doable but doesn't feel elegant like so many other things in the framework. I did do tests, and the UUID and random string work together so I was able to make the change without old sessions breaking.

…

On Fri, Jan 6, 2023, 8:17 a.m. Dries Vints ***@***.***> wrote: We're not planning on a config option at this time. You can use Ramsey uuid or symfony one directly. You can overwrite the methods on HasUuids trait. — Reply to this email directly, view it on GitHub <#44210 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYE5QKS5H6LT4SUPPP34ODWRAZQJANCNFSM6AAAAAAQQGLJTI> . You are receiving this because you were mentioned.Message ID: ***@***.***>