[11.x] Add column type for native UUID

[staudenmeir]

With the new dedicated driver, MariaDB users can now benefit from the native column type for UUIDs (Laravel uses char(36) at the moment).

This would be a breaking change for existing applications, but since the driver is new, users have to consciously switch to it and will be made aware of this change. They should convert their existing UUID columns to the native type. I'll document it in the upgrade guide.

[taylorotwell]

Not totally sure I want the breaking change if people opt-in to this. 😬 I wonder if a nativeUuid method would be better? Or even uuid()->native() which I think I like even more.

[hafezdivandari]

But user expects uuid type when declaring uuid column? We already use uuid type on pgsql and uniqueidentifier type on sqlsrv, and it fallbacks to char(36) on MySQL. Isn't it totally expected to have uuid type on mariadb when it's actually supported?

[taylorotwell]

It's more about the breaking changes involved. If you already have an app in production using uuid() where it creates a char(36), then you upgrade to Laravel 11 and setup a new dev machine, your column locally is now a native UUID but production is a char(36).

[hafezdivandari]

I understand, but I think it's easier to explain this on the L11 upgrade guide (user may explicitly use ->char('uuid', 36) if they want), than explain this on the migrations docs that it's sometimes a UUID and sometimes not.

But if we are going to use a modifier, I suggest ->strict(). We can use this on some other types on SQLite too, to be able to enable strict mode: https://www.sqlite.org/stricttables.html

[staudenmeir]

I wonder if a nativeUuid method would be better? Or even uuid()->native() which I think I like even more.

@taylorotwell Would you make this a MariaDB-only method/modifier or should it work with all DBMS that have a native column type for UUIDs (MariaDB, PostgreSQL, SQL Server) and throw an exception for all other DBMS?

[taylorotwell]

I think it would work on all databases that support it and throw an exception on other DBs.

[johanrosenson]

We are using MariaDB and UUID's and I would prefer the breaking change over a native() method. The breaking change is a one time effort required when upgrading, the native() is something everyone have to keep doing forever.

The breaking change better aligns with what we expect: a native type if possible, or a generic fallback.
We have always assumed that whenever a native type becomes available, the type methods would be updated to reflect the current best available options.

The upgrade guide would have to mention this of course and maybe the upgrade guide could give a small code example of how to convert existing char(36) to proper uuid type in a migration.

[staudenmeir]

@johanrosenson I personally also prefer the breaking change. If there is ever a good time for this, it would be now.

@taylorotwell I reverted the changes and added the nativeUuid() type. I looked into uuid()->native(), but since modifiers can only add SQL after to the column type, we can't use them to replace char(36) with uuid without changing quite a bit of code.

There are three helper methods for UUIDs: foreignUuid(), uuidMorphs(), and nullableUuidMorphs()
Do you want to have equivalents for native UUIDs?

[taylorotwell]

Decided to just go with your original commit of using native UUID on uuid method. 👍