[9.x] Add UUID support to native castables

[ollieread]

This is a small PR which adds support for the castable type uuid. Since we have a uuid option for migrations, it only makes sense that we also support adding it as a castable type.

I appreciate that it does couple models with the ramsey\uuid package, but that is included in the framework, and has been for some time.

[taylorotwell]

@ollieread does the corresponding "set" operation already just work because UUIDs are stringable? Any tests?

[ollieread]

@ollieread does the corresponding "set" operation already just work because UUIDs are stringable?

@taylorotwell The Uuid instance does have a magic __toString, but the interface I've used in docblock does not. Happy to change it if you think that's best?

Any tests?

Happy to add some.

[ollieread]

@taylorotwell Tests added as well as some better handling for converting between strings and UUIDs

[ralphjsmit]

Awesome idea!

[driesvints]

Please mark as ready if you want another review.

[DarkGhostHunter]

Can be this replicated for ULID too?

[driesvints]

Readying this for review again so Taylor can review @ollieread's answer here: https://github.com/laravel/framework/pull/43978#discussion_r967836179

[taylorotwell]

So - I think this PR looks generally fine, but I am curious what the usefulness of it is. What would I want to do with a UUID object? I understand creating domain specific ID value objects like ProductId, etc. where maybe you have some extra functionality on the object. But, what would I do with a plain UUID object? Why not just use a string? What are the actual benefits?

[DarkGhostHunter]

Why not just use a string? What are the actual benefits?

The database may be using a binary column (recommended by MySQL) to store UUID. I need a native castable to retrieve the binary as UUID, even if is transformed to a string. And then, from a string to a binary form.

I think this PR falls relatively short because the idea of a native castable is to transform whatever the database spits as UUID, and whatever the app receives back to what the database is using. That could be fixed by allowing the UUID to be binary by using uuid:string (default) and uuid:binary:

protected $casts = [
    'user_id'    => 'uuid',        // The column type is a string.
    'article_id' => 'uuid:ulid',   // The column type is a 26-char string.
    'image_id'   => 'uuid:binary', // The column type is binary.
];

With this, all bases are covered. I think It may open this to use them as primary key types in Laravel 10:

protected $keyType = 'uuid:binary';

And open up ULID casting like ulid, ulid:uuid and ulid:binary.

[taylorotwell]

Going to hold off on this for now. Can easily write a custom cast if you wish.