Comments on: Resolved: Should schema.rb be included in your source control?

By: Dumping and restoring data with the YamlDB gem « Silence is Foo

Dumping and restoring data with the YamlDB gem « Silence is Foo — Mon, 19 Jul 2010 20:05:46 +0000

[...] and restoring data in YAML format. It complements the database-independent schema format found in db/schema.rb. The data is saved into [...]

By: 室內設計

室內設計 — Wed, 03 Dec 2008 10:46:21 +0000

We needed this because we do a lot of our experimental development in branches and therefore development database can contain things you don’t want to make their way to production right away.

By: Lar Van Der Jagt

Lar Van Der Jagt — Sat, 06 Sep 2008 17:21:51 +0000

In the early stages of development while things are still fairly volatile I like to be able to blow out and rebuild my database on demand. Until the app goes into production I usually give each model it’s own migration and just update that as the schema evolves, dropping & recreating the db as I go.

I use Michael Bleigh’s seed_fu to manage my seed data (can be found on github). True I need to keep seed data in synch with schema changes, but unlike using fixtures for this purpose the seed data comes from ruby scripts so you can get around the more common issues with careful scripting.

Of course this strategy won’t work for production, once I’ve got some more experience deploying my own apps I may have to reassess this method.

By: Antares Traders Blog » The schema.rb Source Control Debate

Antares Traders Blog » The schema.rb Source Control Debate — Wed, 23 Jul 2008 19:40:13 +0000

[...] Rappin has written a post at Pathfinder about whether or not schema.rb belongs in source control. I’m going to put my two cents in and say it does. The debate centers on the role of [...]

By: Anthony Caliendo

Anthony Caliendo — Mon, 21 Jul 2008 22:29:48 +0000

For those of you who mention that your migrations will fail after modifying the model/removing models, I have two comments:

1) In order to maintain that your migrations work with a clean DB, you can setup cruise to always start with a clean DB. I always configure cruise to run “rake db:migrate:reset” before it runs the tests. If the migrations have been broken, cruise breaks and you can fix the migrations.

2) I do not think that you should be doing any sort of manipulation in the migrations which would break if the model changes. That means that loading fixtures or what-not in the migration should be avoided; the only data manipulation should be when you need to massage data to fit into the new schema (i.e. migrating existing data in your DB to fit the new schema). Make sure that your ‘down’ does this migration in reverse! If you really need to load up fixtures or something outside of pure data migration (loading up default values is NOT data migration!), then create separate rake tasks to do this. You can then customize your build to run these rake tasks as needed.

I’ve seen far too many migrations break because there wasn’t proper separation of concerns in the migrations.

By: Matt

Matt — Mon, 21 Jul 2008 15:20:38 +0000

I consider the db/schema.rb to be the the official database structure, however, I also verify that my migrations can execute properly with an empty database. It is not that difficult to keep the migrations working even when removing models from your code.

By: Xavier Shay

Xavier Shay — Mon, 21 Jul 2008 04:45:40 +0000

We do what Justin does – recreate from production DB.
Migrations aren’t feasible to keep clean (or even restore from if they were) once you have 700 of them.
schema.rb would then seem appropriate, but
- it doesn’t include static data (a separate rake task would need to be kept up to date for this)
- more often than not it results in conflicts. Ideally every developer should have exactly the same DB but in practice this does not work for us. Copying tables for back up purposes, quickly switching on to a branch with migrations, subtlely different encoding settings/MySQL revisions, etc.

For a long time we tried keeping schema.rb in source control, but we never once restored from it, and it was the #1 source of conflicts when commiting, so now we’ve ignored it.

By: Brennan

Brennan — Mon, 21 Jul 2008 00:32:07 +0000

I’m a fan of auto-migrations. http://errtheblog.com/posts/65-automatically

As for being able to see the progression of the DB, isn’t that what source control is for?

By: Stephen Veit

Stephen Veit — Sun, 20 Jul 2008 13:31:58 +0000

@Darren: We never use an external model class from inside a migration because of the fact that it might go away. If we need to access a model, we define the model class inside of the migration class where is is used. This allows to always be able to run our migrations from scratch, even if an old model has gone away. I treat schema.rb as a generated file.

By: darkstego

darkstego — Sat, 19 Jul 2008 20:40:38 +0000

One of the things that I found frustrating about rails is trying to get a good grasp of the database schema by figuring out multiple migration files. Which is why I found the plugin automigrations to be so useful.

I believe the incremental nature of migrations has some advantages but it kinda falls in an area of “should be handled by SCM”. Looking at increments makes it very difficult to grasp the whole picture, and as development grows a lot of defunct migrations get piled up which serve no purpose other than causing errors during migrations.

It would be interesting to see if one could come up with a solution that provided several of the advantages of migrations (data entry, raw SQL) into a solution that does not pile up incremental files.

Maybe if migrations could be flushed at certain stable points. And the schema.rb becomes a single migration file at that point.