search

ramsey / uuid-doctrine

:snowflake::file_cabinet: Allow the use of a ramsey/uuid UUID as Doctrine field type.
MIT License
893 stars 84 forks source link

Additional usage of UUID v6/v7 for UuidBinaryOrderedTimeType #187

Closed Seros closed 1 year ago

Seros commented 1 year ago

Usage of UUID v6/v7

As the versions 6 and 7 of UUID are about to be finalized and also already be supported by ramsey/uuid would it be possible to make the UuidBinaryOrderedTimeType configurable to switch between existing v1 and new v6/v7. These new version could come with improvements regarding the their generation and application as a primary key in MySQL.

Background/problem

The usage of v1 in UuidBinaryOrderedTimeType is fine so far but regarding different articles the new v6/v7 provide improvements of their generation and feature set. v7 even gets rid of all not needed features and makes it a nice candidate for using it as field type or even primary key in DBMS like MySQL 8.

Proposal/solution

Make it configurable what version of UUID is used for UuidBinaryOrderedTimeType and ensure that the existing data set sticks to that version in future migrations to prevent data inconsistency.

Alternatives

I thought of overwriting the class but this feature could be useful for more cases.

ramsey commented 1 year ago

I think this is a good idea.

tsurowiec commented 1 year ago

@Seros @ramsey I think new UUID versions deserve separate types and generators. Since version 7 is encouraged I think I would go only for this version in implementation (ignoring v6 altogether). The type would be uuid_binary_v7 with a dedicated generator. WDYT? I am able to prepare PR if you would agree to the proposed solution.

tsurowiec commented 1 year ago

also I think after v7 is introduced, the uuid_binary_ordered_time should be marked as deprecated 🤔

ramsey commented 1 year ago

@tsurowiec Agreed. I've already released a version with v7, but I need to deprecate the other, non-standard classes. I'll soon include v8, as well.

Make it configurable what version of UUID is used for UuidBinaryOrderedTimeType and ensure that the existing data set sticks to that version in future migrations to prevent data inconsistency.

@Seros Do you have any thoughts on how to accomplish this?

Seros commented 1 year ago

I'm not sure but I also don't see it as a blocker. Having the possibility to choose the kind of UUID for the type would be enough for now.

tsurowiec commented 1 year ago

@ramsey it seems that what we were missing here was the generator with V7, the uuid_binary is handling the rest just fine. I added the PR, adjusted the documentation (and since English is not my first language, you might want to check this)

https://github.com/ramsey/uuid-doctrine/pull/191

ramsey commented 1 year ago

I merged #191, and this will be included in the next version!