1

I understand the reason for migration files when making changes to the database but assuming everyone has migrated (all servers are up to date) or you're a single developer why keep a long history of migration changes when you can remove them all and just use the schema?

Example. I've been playing with my db schema so I've changed one field five times with five different migrations. It seems silly to keep these now that I know what the field should be so is it bad practice to delete them and just keep the schema?

Ryan Detzel
  • 5,519
  • 9
  • 37
  • 49

1 Answers1

1

I'm currently working on an extension of an already up-and-running application. I work as a single developer but I have 3 instances of the application:

  • Development Environment
  • Staging Environment (own server)
  • Production Environment (own server)

On the production environment the application is already in heavy use. If I wouldn't work with migrations but only with the schema the production environment would loose data since the whole schema would be re-loaded and not additionally migrated.

That's my personal take on that :-)

Vapire
  • 4,568
  • 3
  • 24
  • 41
  • Thanks, I understand that. Maybe my question should be around new applications and if you're just starting out is there a reason to keep migrations as you're creating the initial schema? – Ryan Detzel Apr 01 '14 at 13:32
  • Well, I think it depends on the situation. If you reach a state where you're satisfied, there's no problem in deleting your un-used migrations. Look at [this](http://stackoverflow.com/questions/20119391/delete-old-migrations-files-in-a-rails-app) answer for additional resource. – Vapire Apr 01 '14 at 20:56