New idea for migrations and seeders.

[Fox4Iit]

If we can make migrations available for editing at any time, even on a production server.
When a migration is being performed, we would check for the column attributes, or the column existence, if it does exists, then move to next, if not, then create it, if it DOESN'T exists, or have a different attribute, it will change or the column will be deleted from the database.
As for the seeder, we would check for the value of the column, if it does exists, then we can resume next.
I don't know how to make this myself, any help or guide to read on how to accomplish that?

[sisve]

If we can make migrations available for editing at any time, even on a production server.

What you're suggesting goes against how migrations are meant to work. Once written they should not change. You should be able to run them again to create an identical database.

Have you looked into similar ideas? #980 and #944 seems relevant.

[Fox4Iit]

@sisve Well, I believe it doesn't. If we made that work, then we can create an identical database. But for an existing database ON PRODUCTION, we can't update the columns. We would drop all tables, then recreate. Or create a migration file for editing only. And this will create a very long chain of files to be migrated. I think you know, customers change their minds each day :D :D So, the best solution to make things easier and more peaceful, is to make the migration handle dropped columns and newly created columns...

[sisve]

I disagree that we need to ability to edit migrations, or even have them change once deployed. However, a schema file (or any source of "this is the way the database should look like) could be used to generate migration files for you. This allows you to verify them before you deploy them, but they should still not be changed after deployment. How does this sound?

[martinbean]

But for an existing database ON PRODUCTION, we can't update the columns.

@Fox4Iit Why can’t you? You can write migrations that add/edit/remove individual columns.

And this will create a very long chain of files to be migrated.

But that’s how migrations are meant to work. Migrations are like source control for your database schema: each change to your schema is represented by a migration file.

I think you know, customers change their minds each day :D :D So, the best solution to make things easier and more peaceful, is to make the migration handle dropped columns and newly created columns...

Your migrations should be dropping and creating columns.