Schema builder like Prisma

[TheBlckbird]

I think it would be really useful if we had a schema builder like prisma.
In prisma you put the schema for a table in a file and when you run a migrate command it looks for changes and updates the database accordingly.
This would be very good because you could add auto-completion to models, but the best part is that you don't have to look at your database to see what rows you currently have, just the schema file.

A schema file could look something like this:

class Flights extends Schema {
    public function schema() {
      Schema::table('flights', function (Blueprint $table) {
          $table->id();
          $table->string('name');
          $table->string('airline');
          $table->timestamps();
      });
    }
}

[henzeb]

What is the difference with the current migration mechanism?

[TheBlckbird]

With the current migration mechanism, you would have to create a new migration file every time you wanted to change something, but with this new system, you only create one schema file for each table where you can define your schema. This means that you only have to change that one schema file when you want to change something. When you run php artisan migrate, Laravel will look at the changes in the schema file and updates the database accordingly.

[Sophist-UK]

Whilst Artisan migrations are often/mostly used to create empty tables or add empty columns, that is not necessarily the case as an Artisan migration is a PHP program which can do other (related things).

So for example, if you were converting your database to use UUIDs rather than auto-increments, your migration code might:

1. Define a UUID primary column, populate it with UUIDs and delete the auto-increment column.
2. Before deleting the auto-increment column, it might create foreign-key UUID fields and run an Update query to link UUIDs to the same records that the big-int foreign-key already links.
3. It might change the foreign-key relationships held inside the database, and delete or create indexes.

And it is easy to imagine much more complex migrations than the above which might include much more significant data transformation.

But I would readily accept that the vast majority of migrations are just adding columns and that the approach suggested by this discussion has merit - though on the other hand, it might be considered added complexity that the Laravel team are unwilling to maintain.

The good news is that Laravel is already a layered system e.g. Eloquent uses QueryBuilder etc. so it seems to me that there is nothing stopping someone from creating a package that is layered on top of Schema (the layer that provides migration functionality) and which undertakes incremental changes. You could even attempt to make it plug-compatible with Schema so that you import and extend IncrementalSchema instead of Schema and the rest is taken care of.

[yuan8]

its good and agree @Sophist-UK . i think laravel has facilitated basic things in this. maybe you can make this package separately. this is because it might be very dangerous for the production server.

maybe the current condition looks less efficient but the good thing is we can use it as confirmation regarding the process that will occur in our database.

[yui019]

Sorry for necrobumping, but I just wanted to come in and say that I've been working on a package like this and I reached a point today where I felt comfortable publishing the first version.

You can look at it on: https://github.com/yui019/hori

I made a couple choices which might be different from how OP imagined it at first, but I think this was the best approach.
Essentially, you run an install command which creates a database/hori directory with a schema.php and an old schema (.old-schema/schema.php). You make your changes to schema.php and when you run php artisan hori:generate, it compares that schema against the old schema, creates a migration according to the differences and updates the old schema to reflect the current one.

This allows you to create your own migrations by updating the old schema manually and creating the migration yourself in case you're not happy with how Hori created it or want to run some special logic in there.

There's a couple things I still need to add, but the main functionality is there for now.