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.

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.

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.

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

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.

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.

We have a system where each new client get’s its own database schema and we don’t want the user wait while migrations are building up their schema on registration. This is where schema.rb really pays off.

For example, we have a database that uses memory tables to hold data that only needs to persist for about 10 minutes, but if we were to do a db:schema:load, the tables would be created as standard INNODB tables that live on the file system.

When it comes to seeding your database, I tend to use take tasks, since they can be more easily be maintained, and don’t depend on a nine month old migration still working with what may be radically different models. I just don’t see the value in making sure tour migrattions still run long after the purpose they were written for has passed.

Apologies for any typos – it seems my iPod doesn’t want me to be able to see what I’m typing

Jon

Migrations are meant to be run over time, as your code changes. That is, a migration should be run with the same source set that it was intended to be run with. Be very careful running them with newer code (i.e., running old migrations with a fresh up to date copy of source).

The database after the migrations should == schema.db. Any descripencies could be the result of some improper migrations, or changes made to the deployed database not reflected in the development schema.

That being said, I don’t employ this as a test currently.

“[schema.rb] is the authoritative source for your database schema”, “running all the migrations from scratch … is a flawed and unsustainable approach” – schema.rb

Andrew

Rails::Initializer.run do |config|
config.active_record.schema_format = :sql
end

which replaces schema.rb with development_structure.sql.

///ark

Worse, if you use the generated schema.rb, it may be incomplete if for example you used execute to run some DB specific code (think trigger, stored procs, etc…;)

Bernard Gallet