Cleaning up migrations

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.