feat(database): add configurable migration naming strategy

[xHeaven]

This PR makes the filename prefix configurable for raw migrations.
Keeps the original Y-m-d prefix and adds a new Uuidv7 prefix. (time-sortable)
The usecase: no collision/confusion/rename need when creating multiple migrations the same day.

[innocenzi]

I love this. What if the interface accepted the filename so the user could have further control over the final name?

[xHeaven]

I love this. What if the interface accepted the filename so the user could have further control over the final name?

Only the filename, or a separate property?

[innocenzi]

I meant this:

interface MigrationNamingStrategy
{
    public function getName(string $filename): string;
}

Not sure if the extension should be given too?

[xHeaven]

I meant this:

interface MigrationNamingStrategy
{
    public function getName(string $filename): string;
}

Makes sense, I can definitely adapt to this. However, object and up name gets generated entirely differently that raw, do you want to streamline them or we want to handle them separately?

Not sure if the extension should be given too?

I don't think so, raw migrations are .sql, object and up migrations are .php since they are class-based, not sure what benefit would it give us to change this.

What are your thoughts?

[innocenzi]

Makes sense, I can definitely adapt to this. However, object and up name gets generated entirely differently that raw, do you want to streamline them or we want to handle them separately?

Ah, good point! I'd say we only use the naming strategy for raw migrations because class ones should follow PSR-4. That would also solve the extension question.

[aidan-casey]

Nice, @xHeaven! I really like this PR also. Given this is merged to 3.x, any reason we cannot a) default to UUIDv7 and b) add a timestamp to the date?

CC: @innocenzi

[xHeaven]

Nice, @xHeaven! I really like this PR also. Given this is merged to 3.x, any reason we cannot a) default to UUIDv7 and b) add a timestamp to the date?

CC: @innocenzi

There is no reason. I was unsure whether I wanted to change Tempest's default behavior, as people tend to have some weird UX fetish towards date'd migrations, for "scannability" reasons. We can definitely default to UUIDv7, in fact, it's a safer default in terms of collisions.

Regarding the timestamp to date, we could either rename the DatePrefixStrategy to DatetimePrefixStrategy and include this, or create a new strategy that includes the H:i:s format. We could also add a TimestampPrefixStrategy that is just a Unix timestamp.

[innocenzi]

Personally I wouldn't want UUIDs by default, it's not exactly nice to "scan" when looking at the file tree. It's quite long and I'm more interested in seeing the rest of the name :)

[innocenzi]

A Unix timestamp strategy would be good though!

[xHeaven]

Personally I wouldn't want UUIDs by default, it's not exactly nice to "scan" when looking at the file tree. It's quite long and I'm more interested in seeing the rest of the name :)

See @aidan-casey, there goes the scanning fetish I was talking about! :D

[aidan-casey]

Sadness. I like the lack of collision while maintaining sorting by time. It'd be nice if you could generate multiple migrations at a time and have them all sorted by order.

Either way, I think we should include a sensible default, which should at least not collide when created on the same day by default.

[innocenzi]

That's still possible without cluttering file names with UUIDs! We could do a file_exists check before writing the file, and increment an id. I'd be fine with shorter IDs instead of UUIDs by default too, but come on, UUIDs are very long.