Imagine a rails app that has two versions that developers need to
support:
1.0 and 2.0. There are 2 database schemas: app-1, app-2.
After fixing a bunch of very important bugs in production (1.0), some
junior developer named Bob switches the branch to 2.0 to implement a few
features but somehow gets his app connected to the schema app-1 and does
rake db:migrate
As I understand, in that case the app-1 schema will be migrated to 2.0.
Considering a fact that migrations are not always reversible, Bob is in
trouble and instead doing useful work, has to restore the db schema.
Imagine a rails app that has two versions that developers need to support:
1.0 and 2.0. There are 2 database schemas: app-1, app-2.
After fixing a bunch of very important bugs in production (1.0), some junior
developer named Bob switches the branch to 2.0 to implement a few features
but somehow gets his app connected to the schema app-1 and does rake
db:migrate
What do you mean by “connected to the schema app-1”? Do you mean
connected to the wrong database or are you talking about schema.rb?
If you mean the wrong db then how? By changing database.yml? How
could he do that accidentally?
Imagine a rails app that has two versions that developers need to support:
1.0 and 2.0. There are 2 database schemas: app-1, app-2.
After fixing a bunch of very important bugs in production (1.0), some junior
developer named Bob switches the branch to 2.0 to implement a few features
but somehow gets his app connected to the schema app-1 and does rake
db:migrate
What do you mean by “connected to the schema app-1”? Do you mean
connected to the wrong database or are you talking about schema.rb?
If you mean the wrong db then how? By changing database.yml? How
could he do that accidentally?
AFAIK it’s recommended that schema.rb is version controller, but
database.yml is not. This is how I always setup my development
environments.
In this scenario each developer has their own version of database.yml,
but everyone shares the same schema.rb.
In this case where you have a v1.0 branch and a v2.0 branch it would
have to be left up to each developer to make sure their development
database matches the schema.rb file of the branch they are current
working on.
The easiest way I know to do this would be to reset the development
database when switching from v1.0 to v2.0 and vise versa.
This will drop and recreate the development and test databases from
schema.rb. No need to worry about irreversible migrations in this case.
The development database will match the appropriate schema.rb regardless
of what happened in migration history.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.