My project has a lot of migrations, that ar not all necessary on my new server, since the database has been copied.
For installation, I simply removed these migrations on the the server, before executing, but that no good solution for further maintainance of the new server.
I'm using vlad as deployment tool. How to cleanup the migrations? Is it possible, to simply remove the unwanted migrations from db/migrate?
Fritz Trapper wrote:
My project has a lot of migrations, that ar not all necessary on my new server, since the database has been copied.
For installation, I simply removed these migrations on the the server, before executing, but that no good solution for further maintainance of the new server.
I'm using vlad as deployment tool. How to cleanup the migrations? Is it possible, to simply remove the unwanted migrations from db/migrate?
Don't. They're not doing any harm, and they may be helpful for future maintenance.
Best,
Marnen Laibow-Koser wrote:
Don't. They're not doing any harm, and they may be helpful for future maintenance.
They harm, they are data migrations, that require data, that may have been changed in the meantime.
Fritz Trapper wrote:
Marnen Laibow-Koser wrote:
Don't. They're not doing any harm, and they may be helpful for future maintenance.
They harm,
How? You're not normally going to be running old migrations. What specific problem do you think you will run into if you leave the old migrations around?
they are data migrations, that require data, that may have been changed in the meantime.
Can you give an example? Are you talking about seed data, or about changing existing data to fit a new schema?
If the former, then you've got a great example of why you shouldn't use migrations for seed data. If the latter, then there's really no issue.
Best,
Marnen Laibow-Koser wrote:
How? You're not normally going to be running old migrations. What specific problem do you think you will run into if you leave the old migrations around?
I moved the complete database from my interim server to the permanent one. This database had been modified by the data migrations and in the meantime some data has been changed. So it's not a good idea, to rerun the data migrations on the new server.
To prevent this, I locally removed the data migrations on the new server before migrating.
On my developmentsystem, they're still present and dont harm, but I guess, they will be pushed up to the server again with my next update and will get run, because there is no corresponding entry in the migration data base.
Maybe, the simplest solution will be, to do something to make them null migrations on the development system.
Marnen Laibow-Koser wrote: > How? You're not normally going to be running old migrations. What > specific problem do you think you will run into if you leave the > old migrations around?
I moved the complete database from my interim server to the permanent one. This database had been modified by the data migrations and in the meantime some data has been changed. So it's not a good idea, to rerun the data migrations on the new server.
To prevent this, I locally removed the data migrations on the new server before migrating.
On my developmentsystem, they're still present and dont harm, but I guess, they will be pushed up to the server again with my next update and will get run, because there is no corresponding entry in the migration data base.
Why is there no corresponding entry in the database? If you initialize a database from db/schema.rb, an entry is created in the migrations table indicating the version of the schema.
Maybe, the simplest solution will be, to do something to make them null migrations on the development system.
Just throw them away. If you can.
Migrations are tools for changing the structure of a database from one version to the next. They have no lasting value. In particular, migrations are *not* the right means to re-create a database. For that, db/schema.rb + rake db:schema:load is the proper way.
Also, migrations are not supposed to add data to the database, apart from changes necessary for migrating the structure. For adding data, there are db/seeds.rb and rake db:seed. It's good idea to write db/seeds.rb in such a way that it can be run again and again without causing harm.
In summary, if you're worried that old migrations may inadvertently be applied to your database, make sure that it contains a suitable entry in its migrations table indicating the actual version of the schema.
Michael
Fritz Trapper wrote:
Marnen Laibow-Koser wrote:
How? You're not normally going to be running old migrations. What specific problem do you think you will run into if you leave the old migrations around?
I moved the complete database from my interim server to the permanent one.
Then the schema_migrations table should have the correct values, so Rake will know not to run the old migrations.
[...].
On my developmentsystem, they're still present and dont harm, but I guess, they will be pushed up to the server again with my next update and will get run, because there is no corresponding entry in the migration data base.
Why aren't there? If the migration was run, its ID will be in the schema_migrations table.
Maybe, the simplest solution will be, to do something to make them null migrations on the development system.
And the right way to do that is to make sure that their IDs are in schema_migrations.
Best,
Thanks for your explanations.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks