Migrations vs. Schema Definitions - It Matters More than You'd Think . . .

Just as you've got an application working, the client goes and changes the goal posts. Whether you need to change the name of properties, add or remove them or break out properties into separate objects (to name just a few common changes), you have to tweak your db schema, data, model, views and often your controllers to handle the transformation. I was thinking about the spirit of migrations in Rails (I'm not a big fan of the implementation as it doesn't automagically refactor your code base or deal with any data transformations, so it seems to me an inefficient approach). Thinking about it, I'm starting to believe that describing transformations rather than describing the point in time schema for my applications might be a much more powerful way to generate apps.

Some Background
Right now I have a collection of XML files that describe my business objects, their relationships, etc. Based on those files, I have a simple routine that compares my database schema to the model and modifies the schema if required. So, if I want to add a new persisted property to a business object, I add a line to the XML file for that business object, run my schema synchronizer and it automatically adds the new column to the appropriate table.

That works really well up to a point, but there are a few limitations. Firstly, it only updates the schema. If a new property should have a default value it does not currently set that default value for any existing records in the table. Secondly, it doesn't do anything to my code or my views. For an "add property" transformation, that doesn't matter much, but if you want to implement a wider range of transformations it becomes a problem.

Let's say I want to remove a property from an object. If I just remove it from the XML file, it will flag the orphaned column in the db (I could set it to delete the column automatically, but I don't as I fear huge data loss from small typos!). But it doesn't automatically flag wherever I use that property in my code or everywhere I try to display it in my views. What would be cooler would be to describe the transformations I wanted to my application (add property, change attribute, turn property into joined object, etc.) and then to be able to run an analysis which would show me any implications it would have on my code base and (if I approved it) that would then transform the database schema, XML config files, the data in the database and my code and view templates automatically. Given that I use a generic getter/setter interface convention (e.g. get("FirstName")), the parsing of the cfc's and template files should actually be fairly straightforward.

I must clarify this is nothing to do with an earlier posting which was focused on implementing grammatical transforms rather than content transforms (same principle but different level). For example, a grammatical change might be removing the SQL data type attribute of the fields of business objects. The kind of transformation I'm talking about here would be about adding a new property to a business object (e.g. FullName) rather than changing the structure of the way that the properties of business objects are described (phew - congrats if you made it through THAT sentence!).

Hmmm, gotta think about this, but it could be an incredibly powerful approach and once I'd come up with a way of handling any given transformation, implementing such transformations in future would just be a matter of describing them in an XML transformation file and "migrating" my apps (not just my db schema).

Thoughts?!