create migration automatically with php attributes

[agus24]

Hi. i have an idea can we use php attributes for creating migration from model only?

Our model would looks like

class Book extends Model
{
    use HasFactory;

    #[Id()]
    public int $id;

    #[String()]
    public string $name;

    #[Text(nullable: true)]
    public string $description;
}

and just call php artisan generate:migration and this would generate migration file with up and down methods automatically

function up() {
    Schema::create('books', function (Blueprint $table) {
        $table->id();
        $table->string('name');
        $table->text('description')->nullable();
        $table->timestamps();
    });
}

function down() {
    Schema::dropIfExists('books')
}

you can have an annotation when access the model and also create the model with migration inside of it. And it would be great if the generate:migration command would read the changes of the model then create migration file that will update the table

[andrey-helldar]

This approach is good for a one-time start.

Now imagine three cases:

1. New fields are added to the model. The script will have to go to the database, check for the existence of the table, check for the presence of existing fields, and then correctly generate the migration file.

2. Suppose initially a mistake was made in the column name. For example, they called the column "naame", then they noticed an error and corrected it to "name". How is the migration supposed to know it's fixing an existing column and not adding a new one? (reference to point 1).

3. Let's say during development you created a migration and deployed it successfully. Then you need to roll back and change it. What will be the actions? Roll back the migration, make changes to the model, generate a new migration file, delete the old migration file, and run again?

If you need to create migrations from existing tables, it's easier to use the https://github.com/kitloong/laravel-migrations-generator package, for example.

[toramanlis]

@agus24 I think this is bull's eye:

https://github.com/toramanlis/laravel-implicit-migrations

@andrey-helldar i think all three points are covered as well.

when the command is run, the existing migrations are taken into account and the differences make another migration.

it allows custom migrations as well. say you renamed a column. you can create a migration file that reflects that. as far as the generator is concerned the column name won't even have been renamed. if you want to update the model to match the rename, you can make the custom migration with the rename visible to the generator too. it's up to you

if you need to rollback a migration and change it, it works as usual. you don't have to delete the migration and regenerate it, you can just update it, and it works.

[macropay-solutions]

@toramanlis laravel is not symfony to define attributes (as in columns from db) as model php properties.

You will have clashes with the active record's php properties.
Also you would have to hack the getAttributes and also getAttribute if not many more methods.

[toramanlis]

Can you elaborate? Why does it have to be symfony to do that? do you mean active record's php attributes? why would i have to worry about clashing with them?

Have you checked the package? I've already implemented this and tested it.

It doesn't define any properties to clash with anything, neither it hacks the getAttributes getAttribute (unless you mean ones in the reflections which i don't see why it should be off limits) or any methods for that matter. It adds literally nothing functional to the model. It inspects the model using reflections and creates a migration file. You don't even have to use php attributes. Everything can be done with annotations too.

[macropay-solutions]

In laravel attributes are: php attributes , Cast\Attribute and model columns but, not php properties. We meant model (active record) columns. Sorry for the ambiguity.

If you write your model like in the above post:

class MyModel extends Model
{
    public int ${name}; //  depending on the name, this can clash with a model php property
}

Laravel handles model columns with $this->attributes property that is defined in HasAttributes trait.

The above will not work when doing something like:

$array = MyModel::query()->first()?->toArray();

Unless you hack some methods from that model.

The lib that you linked has nothing to do with our observation.

[macropay-solutions]

To be more precise

class MyModel extends Model
{
    public int $exampleProperty;
}

$model = MyModel::query()->firstOrFail();

$model->exampleProperty = 3;

dd($model->toArray); // will contain only the db values but not the 3 from above even if the column exampleProperty exists in db.

class MyModel extends Model
{
    public int $value;

    protected $fillable = [
        'parent_id',
        'client_id',
        'currency',
        'value',
        'created_at',
        'updated_at',
    ];
}

$model = MyModel::query()->create([
        'parent_id' => null,
        'client_id' => 5,
        'currency' => 'EUR',
        'value' = 10,
]);

$model->value = 3;

var_dump($model->toArray); // will contain value = 10

echo $model->value; // 3
echo $model->getAttribute('value'); // 10

[toramanlis]

thanks for the clarification and i'm happy to say that this case is covered. the package allows defining columns without the corresponding properties existing in the model and vice versa, you can have a property and choose to keep it exempt from the migration generation. i agree that hacking into getAttribute would be too invasive for inferring the existence of columns, so i just didn't do anything of the sort. if a column is invisible without doing so, then it counts as the developer prefers it that way.

[macropay-solutions]

Congrats for the lib.

Again, the lib has nothing to do with what we pointed out here.
The only thing is that if someone uses laravel model like presented in this discussion (with or without the library), it will have many headaches from a laravel perspective.

We handled this properties/attributes clash with a separate class while laravel recommends using $model->setAttribute('fillable') and $model->getAttribute('fillable') when a clash exists.