This PR proposes a single Uid constraint and allows the user to choose the UID types between ULID, UUID_V1, UUID_V3, UUID_V4, UUID_V5 and UUID_V6 (multiple values possible).

According to the feedbacks received so far, it looks like some people would prefer to have not only one single Uid Constraint, but 2 constraints:

• a Ulid Constraint
• a Uuid Constraint

It's ok and i will update my code accordingly. But we have to take a few decisions about the Uuid Constraint. Indeed, there is already a Uuid Constraint in Symfony: https://symfony.com/doc/current/reference/constraints/Uuid.html So the purpose would be to update this existing contraint in order to use the new Uid Component.

But this existing constraint has a strict option: https://symfony.com/doc/current/reference/constraints/Uuid.html#strict There is no notion of strict or loose in the new Uid Component. Should we just deprecate this option?

By the way, the existing constraint can valid V2 UUID versions. V2 is not handled in the new Uid Component. Should we juste use the Uuid::isValid() method and check for number 2 at proper position to valid UUID V2 uuids?

Should we also accept UUIDs encoded in base 58 and 32?

I'd vote to create a single constraint for all kinds of Uids.

That would be consistent with what we already do in other constraints:

• A single Ip constraint validates IPv4 and IPv6, which are completely different between each other
• A single CardScheme constraint validates all kinds of credit card numbers, which are completely different between each other

IPv4 and IPv6 are both different versions of the IP adres. "UID" is just an abbreviation for a fancy name, it does not define a specific string or format. E.g. uniqid() can also be called a UID. Anything that is an identifier and is unique is a UID.

That's why I don't think a single constraint makes sense. Also, as said in the comment of @guillbdx, there is already a UUID constraint. So it makes sense to focus this PR on updating the UUID constraint and introducing a ULID one.

About loose/strict: We can keep it imho. Loose will validate just the string as it's doing atm, the strict variant will use the UID component.

Thanks @javiereguiluz and @wouterj I will wait for other feedbacks to see what are the other pro and cons.

I agree with @wouterj
I also think we need a way to accept short representations of these ids (in URLs typically.)
I don't know exactly how this would all work together (with entities esp.) so let's iterate and figure out.

@guillbdx Still interested in working on this PR? @wouterj and @nicolas-grekas agree on a way to move forward.

@fabpot I won't have time to work on it for a while, would be better that someone take it over.

Thanks for the head up. As there is an associated issue, let’s close here.