36

I'm looking to generate a migration file from the schema.rb. is it possible?

I have many migration files at the moment and would like to combine everything into one master migration file.

I also think i may have accidentally deleted a migration file at some point.

thanks for any help

hanumanDev
  • 6,592
  • 11
  • 82
  • 146
  • Although technically it's possible to combine migrations, I think it's a really bad idea.. don't do it! and use a good version control system, e.g. Git – Tilo Oct 02 '11 at 23:12

2 Answers2

62

You could copy and paste schema.rb into a migration and back-date it (e.g. change the date) so that no existing databases will run it. After you create this migration you can delete all your old migrations.

I disagree with Andrew that you should never delete migrations. Migrations break unexpectedly all the time based on model classes changing and it is very non-trivial to fix them. Since I'm sure you are using version control, you can always look back in the history if you need them for reference.

ghempton
  • 7,777
  • 7
  • 48
  • 53
  • 6
    I humbly suggest that migrations should not depend on model classes, or they will be guaranteed to break over time as your models change. If you need the power of a model, you can include a simplistic, disposable model definition in the migration itself. – David Keener Jan 02 '14 at 21:34
  • 5
    While nice in principle, this is hard to enforce in practice. – ghempton Jan 03 '14 at 00:00
  • 8
    @ghempton, thank you for actually answering the question as written instead of saying, "there is no need to do this". There are always needs and reasons to do something with which others may disagree. – Midwire Jul 07 '15 at 16:09
  • 2
    BACKDATING DID NOT STOP MIGRATION FROM RUNNING. Rails 4.2 . See here http://stackoverflow.com/questions/12057408/how-does-rails-keep-track-of-which-migrations-have-run-for-a-database. – dsieczko Jan 12 '16 at 01:34
  • 1
    I inserted the timestamp part of the rails migration file directly into the 'schema_migrations' table under column 'version' for the server I did not need to run the migration created from the schema. – dsieczko Jan 12 '16 at 03:09
  • 1
    What worked for me is to create an empty migration, get it via our usual workflow to run on the server (thus making server remember that it already run the migration) and then put the schema there and delete all previous migrations. Probably the only occasion where editing the already applied migration can be a good idea, 'cause it will not be re-applied. – Ivan Kolmychek May 22 '17 at 12:49
26

There's no need to do this. For new installations you should be running rake db:schema:load, not rake db:migrate, this will load the schema into the database, which is faster than running all the migrations.

You should never delete migrations, and certainly not combine them. As for accidentally deleting one, you should be using a version control system, such as Git.

Andrew Marshall
  • 95,083
  • 20
  • 220
  • 214
  • 7
    Could you provide some evidence this is bad idea? – Tomek Paczkowski Dec 21 '11 at 11:08
  • @Tomek That deleting/combining migrations is bad? It's pretty much the same reason you'd never really want to delete old commits. Migrations provide a history of your database. There's really not much of a reason to, anyway. I've worked on projects with hundreds and hundreds of migrations and at one point early migrations were collapsed because there's just no way we could ever rollback that far anyway, and a few other reasons. But it wasn't my decision. Like I said, though, for the most part there's not really any point in merging migrations (deleting should never be done). – Andrew Marshall Dec 21 '11 at 17:08
  • Also, like Gordon says in his answer below, it is possible older migrations are corrupted because of the deferring state of the application. In almost all cases this can be avoided by minimizing the use of models in your migrations, and possibly stubbing them. People always seem to be afraid to use SQL in migrations—but it's a migration! SQL is more durable since it doesn't depend on your application. – Andrew Marshall Dec 21 '11 at 17:12
  • 3
    I always thought that point of using migrations is to be able to use more convenient language than SQL and to reuse code you have written already. I had good thought about deleting migrations and, as you should use schema:load instead of migrate and you should keep your code in VCS, there should be no harm in deleting old migrations. It just dead code that's never executed. – Tomek Paczkowski Dec 22 '11 at 09:20
  • I agree that normal practice should be to keep all migrations and use new migrations to modify the database rather than to modify migrations. – ReggieB Jan 30 '13 at 08:44
  • There is one place where consolidating migrations can make a lot of sense: when you are building an engine. Migrations from the engine are copied from the engine into the host. I don't think most app builders will want a huge chain of development migrations copied into their app when they use your engine. It makes sense to consolidate migrations before you first release the engine. – ReggieB Jan 30 '13 at 08:51
  • 4
    In a perfect world you don't want to delete migrations, but... another real-world case to delete/reset migrations is if someone modified the database from the commandline and the changes were never added to migrations (ie. someone f'ed up the flow). These scenarios may make resolving the differences between migrations and the database difficult to identify, and thus may warrant doing a new schema dump, removing all existing migrations, and then loading the current schema into your new first migration. – bob Sep 12 '13 at 17:31
  • The reason I am creating a migration from my `schema.rb` is that I am merging two Rails applications that currently have two different databases. I'm using the `schema.rb` from one project to create the tables in the other project. – davew Sep 17 '21 at 20:10
  • The only issue here is data migrations. If you rely on db:schema:load you need another way to load your data. Though, that's probably for the best anyway – Peter Gerdes Apr 26 '22 at 23:06