techno.blog("Dion")

Pairing today, I saw someone go through the following process:

• Went to play with some SQL as we prototype a new feature
• Say ’screw it’ and jump in to use migrations to change the schema as it was easier to do so that grok the SQL in this case

This again showed me how ActiveRecord migrations are so useful, that I would be very tempted to use them for a non-Rails project at this point.

That isn’t that far fetched. I can not think of a Java project in recent years that didn’t have a bit of Ruby (or Groovy, or …) in there as helper scripts at the very least. There are no “Java projects”. You always have many languages involved (SQL, shell scripts, HTML, XML, …) in a project. As you do useful things in your projects you often generalize them into libraries that you use on future projects.

ActiveRecord migrations could easily fit into this world. Versioning, and managing the versions of database schema, and data, can often be a pain in the arse. Migrations does the job in style, and is useful standalone.

Of course, you could role up some Java solutions, but it is hard to come up with a DSL quite as nice, and migrations will get better and better. There are still rough edges that we run into. When sucking out an existing schema with enumerations a field with varchar(0) was created. Not too helpful, and yet another look into how good Rails is for green-fields, but it still takes a bit more work for legacy. This is normal though.