Should Blueprint::uuid() have the option for making the column unique?

[cosmastech]

• Laravel Version: 10.5.1
• PHP Version: 8.2.0
• Database Driver & Version: MySQL 8.0.31

Description:

Didn't want to go down the rabbit hole of writing the code for this if it would just be rejected outright, but it seems like the Blueprint@uuid() method should have an argument to make the column unique.

I think for most developers, they see UUIDs as a big benefit for security, but when they aren't indexed at all, they require a full table scan. Nudging the developer to make the column unique has twofold benefits:

1. If a column is unique, it's indexed
2. I would guess that 9 times out of 10, a UUID column is functioning as the public facing index for a table, and therefore is expected to be unique.

There are of course cases where uniqueness is not desired, which is why I'm suggesting an optional argument. To maintain backwards compatibility, the optional argument would default to false.

What I was thinking was:

public function uuid($column = 'uuid', bool $makeUnique = false)
{
    $columnDefinition = $this->addColumn('uuid', $column);
    return $makeUnique ? $columnDefinition->unique() : $columnDefinition;
}

I realize that it's as simple as a developer chaining a call to unique() after their column definition, but I think this pushes developers into better practices. I can't count how many times I have had to write a second migration (when queries were interminably slow on production) or migrate:fresh once I realized the column wasn't already unique.

I'll happily add this to 10.x (or 11.x?), just don't want to waste my time for the PR to be closed, so I thought I would ask first.

If we were to go the 11.x route, I would suggest making the argument default to true and list it as an Impacting Change.

Steps To Reproduce:

[cosmastech]

Thanks for converting this to a discussion @driesvints

[crynobone]

https://twitter.com/taylorotwell/status/277969747302305793?t=JO8SMeBrE736nbLyz20aFw&s=19

Since the method can be chained, an additional may not be needed.

[cosmastech]

Is anything preventing you from doing $table->uuid()->unique()?

Nope, not at all. However, I personally feel it's a significant improvement to developer experience that this would be set as the default.

Only after working on a Laravel application with a large-scale database did I learn about the importance of a well-indexed database. Also, like I said, I've run into releasing a feature to staging (or production 😟) only to find out that I forgot to add the index and an endpoint which was fine on my local environment crawls on a large dataset.

I'm not saying there aren't ways around it, but I have always appreciated Laravel being so opinionated that it pushes me towards best practices.

[driesvints]

To be fair, I also think it should be unique by default but it's been implemented for so long like this that I don't know if it's worth the breaking change.

[Angel5a]

Just introduce new uniqueUuid() without condition, to make the difference obvious, and so we won't struggle that uuid is unique by default, but ulid isn't. Also no BC involved.

[cosmastech]

Just introduce new uniqueUuid() without condition, to make the difference obvious, and so we won't struggle that uuid is unique by default, but ulid isn't. Also no BC involved.

I imagine if I put up a PR to add uniqueUuid(), it would be closed with a form message about making it into its own package.

Secondly, I have always liked that Laravel has strong opinions and pushes developers in the direction of best practices. I think it's better if the framework makes it harder to use bad practices. An unindexed, non-unique uuid column (which literally stands for universally unique identifier 😮‍💨 ) is a terrible practice, in my opinion.