Add support for symfony uuid

[VincentLanglet]

Closes #682

[whataboutpereira]

Thank you, works nicely here.

[ondrejmirtes]

Same points apply to UuidTypeDescriptor.

[ondrejmirtes]

Coding standard failures here

[ondrejmirtes]

Thank you.

[wjzijderveld]

How would you recommend dealing with the different subtypes?
type mapping mismatch: database can contain Symfony\Component\Uid\Uuid but property expects Symfony\Component\Uid\UuidV7
In essence the error isn't wrong, the database could contain anything in theory, but it feels a bit weird having to specify a less specific typehint on my entity if I know its v7

[VincentLanglet]

Is there a benefit to typing to Uuid7 rather than Uuid ?
Extra methods ?

Is it sure to be an Uuid7 ? Even if you migrate manually a value in database directly ?

So far I would say an easy way is to ignore it in the baseline.

[wjzijderveld]

The benefits of uuidv7 are in (time) sortability and indexability. Hence we want to be strict about it, as it's important in our systems. But it's a bit of a grey area, we obviously validate its v7 in our domain code where we generate it, so there's an argument to be made that the persistence layer only cares about the fact its a UUID and not about the specific version.

The argument about manually migrated data seems irrelevant to me, that's exactly what these doctrine types are for, to be able to verify that during persistence/fetching. With the generic UUID type it also wouldn't guarantee that the database doesn't contain random strings.

[VincentLanglet]

The argument about manually migrated data seems irrelevant to me, that's exactly what these doctrine types are for, to be able to verify that during persistence/fetching.

But the purpose of the EntityColumn rule from PHPStan is to avoid possible crash. PHPStan has right to say you could have manually inserted a non-uuid7 in the database and it will be loaded as another Uuid.

The same way if you type a nullable field with private string $myNullableField PHPStan report the possibly null error even if the doctrine type will always be a string. So it's more an issue about Symfony only exposing one doctrine type uuid rather explicit uuid7 etc (which could be a good feature).

And again if you think this error is unrelevant, the pattern is easy to ignore.

[ondrejmirtes]

Unless the Doctrine type guarantees UUIDv7 will be assigned to the property, this reported error is valid.