Log in

No account? Create an account
Chaz Meyers [entries|archive|friends|userinfo]
Chaz Meyers

[ website | chazmeyers.com ]
[ profile | view profile ]
[ archive | view archive ]

[Links:| chazmeyers.com Twitter ]

Why `rake db:migrate` is slow against large databases. [Feb. 19th, 2009|05:04 pm]
Chaz Meyers
I just realized why `rake db:migrate` takes so damn long at work.

Rails is generally designed assuming that the application will get its own database. This is normal in environments where "database" is a lightweight concept, as in MySQL, PostgreSQL, or SQLite. After updating the database, it dumps the database schema to a file so when you install a new copy of the application you don't need to run dozens of migrations.

This works fine when there aren't many tables unrelated to your application, but in Oracle-land it's not unusual to put tons of applications all in the same massive database. Consider the following:

SQL> SELECT count(*) FROM all_tables;


Every time I add a single column to the database via migrations, all those tables get introspected and transformed into 13.5K lines of ruby. A three minute tax is added to an operation which usually takes less than a second.

I wonder if there's some way to turn off this behavior without hacking up their Rake file.

Update: Turns out this only happens if ActiveRecord.schema_format = :ruby. Change it to :sql and it won't try to dump the database.