Monday, January 15, 2007


The rails development mail list at RHG is busy at any day, holidays included: trunk is broken, again ... Please stop bouncing Dev ... new build delivered to QA ... [SVN COMMIT] rhg r40941 ... IE+HTTPS+XML+NoCache=Bad ... Another topic often seen there is TOD for Tip Of [the] Day. Here is an example of such tip:

Prefer atomic migrations

There is a potential issue with any db migration that tries to do more then one thing. For example, if a migration adds three indexes and the second one fails, because a key is misspelled, the migration is stuck. When the key name is corrected, the migration still won’t pass on a DB where it was originally run (read on forty workstations of your fellow coworkers who just updated the code and run migrations ). This time it would fail on the first index creation, because it was created by the failing migration and was not rolled back due to the nature of rails migrations.

The obvious solution for such problems is to make all migrations atomic. If there is a need to add three indexes, there should be three migrations. Instead of adding a table, populating it with data, and adding an index, all within a single migration, there should be three of them, with data population wrapped in a transaction.

No comments: