UUIDs and the nova_notifications & action_events tables.

[Israel5]

• Laravel Version: 9.45.1
• Nova Version: 4.19.5
• PHP Version: 8.2.0
• Database Driver & Version: PostgreSQL 15.1
• Operating System and Version: macOS Ventura 13.0.1
• Browser type and version: N/A
• Reproduction Repository: https://github.com/Israel5/uuid-nova-issue

Description:

Hi folks,
I don't know if it's exactly a bug, but I'm having issues when I try to use UUIDs and Nova.

I use UUIDs across all my Laravel models, and it in general works as expected, except for the nova_notifications and action_events tables.

I'll give the below example using the nova_notifications table, but the same applies to the action_events table.

Apparently, it doesn't understand that I'm using UUID instead of the numeric ID, so the 'notification_id' field is incorrectly generated as integer instead of UUID.

Detailed steps to reproduce the issue on a fresh Nova installation:

On a fresh Nova installation, change your user migration to use UUID instead of ID.
database/migrations/2014_10_12_000000_create_users_table.php

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->uuid('id')->primary();
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }
    ...

Create a trait to handle UUIDs in your models.
app/Traits/Uuid.php

<?php

declare(strict_types=1);

namespace App\Traits;

use Illuminate\Support\Str;

trait Uuid
{
    /**
     * Boot function from Laravel.
     *
     * @return void
     */
    protected static function boot(): void
    {
        parent::boot();

        static::creating(function ($model) {
            if (empty($model->{$model->getKeyName()})) {
                $model->{$model->getKeyName()} = Str::uuid()->toString();
            }
        });
    }

    /**
     * Get the value indicating whether the IDs are incrementing.
     *
     * @return bool
     */
    public function getIncrementing(): bool
    {
        return false;
    }

    /**
     * Get the auto-incrementing key type.
     *
     * @return string
     */
    public function getKeyType(): string
    {
        return 'string';
    }
}

Then import it to your User model.
app/Models/User.php

<?php

namespace App\Models;

// use Illuminate\Contracts\Auth\MustVerifyEmail;

use App\Traits\Uuid;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasApiTokens, HasFactory, Notifiable, Uuid;
    ....

To be able to test your application, run the command php artisan nova:user to add a new user.

Results

As can be seen, the user is created as expected.

The error can be seen when you log into your Nova application:

SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input syntax for type bigint: \"95187e03-feca-434d-b94c-ad596c8298f9\"\nCONTEXT:  unnamed portal parameter $1 = '...' (SQL: select * from \"nova_notifications\" where \"notifiable_id\" = 95187e03-feca-434d-b94c-ad596c8298f9 and \"nova_notifications\".\"deleted_at\" is null order by \"created_at\" desc limit 100)"

Nova is querying a string value in a numeric field.

Up to this point, I thought that for any reason, the migrations were not understanding that I was using the UUID trait, and decided to set the $keyType = 'string' and the $increment = false directly in my model.

I have even set the $keyType = 'uuid' just in case, but the results were the same, the migrations are still creating the nova_notifications table with the notification_id field as integer.

Going deeper

Checking the file vendor/laravel/nova/database/migrations/2021_08_25_193039_create_nova_notifications_table.php, I can see that the migration is using $table->morphs('notifiable') to generate the notifiable_id and notifiable_type fields.

I see that behind the scenes, the morphs method is checking the Builder::$defaultMorphKeyType === 'uuid' to determine whether the fields should be generated as UUID or not, and I'm not quite sure how that actually works, or where do I set it as UUID.

As a workaround, I've copied this migration to my database/migrations folder and I changed it to use $table->uuidMorphs('notifiable'), and it worked as expected.

I'm wondering if this is a bug, or if I'm missing something here, maybe something I didn't see in the documentation.
If I'm missing something, what could I do to solve this issue?

Thanks in advance for the help.

[crynobone]

If all models in your application use UUID (string) as the primary key then you should be able to run the following:

$this->app['db.schema']->morphUsingUuids();

Typically from App\Providers\AppServiceProvider

[xdubois]

Note for people running into the same issue, this need to be done before running the migration

Default value is 'int' as seen here https://github.com/laravel/framework/blob/10.x/src/Illuminate/Database/Schema/Builder.php#L46

[Radiergummi]

@crynobone and what if only some models use UUIDs..?

[crynobone]

It is something you have to deal with if you want to use such structure. A column would need to be string and you would see some performance penalty (if any).