add ability to manually execute sql script with migrations

[GoogleCodeExporter]

Background:
We're using migrations for a few projects already, and it works great.  We just 
started using it on a reporting project, where there are a lot of stored procs, 
functions, and views.  Changes go in migration scripts, but the trouble is that 
because every change is a new file, you can't diff their changes like you can 
with other source code (java files etc).

We'd like to treat these kinds of DB objects as source code, and store them 
like this.  e.g.:
src/db/objects/SearchTransactions.Procedure.sql
src/db/objects/SearchFoos.Procedure.sql
src/db/objects/SomeBig.Procedure.sql

This way, as developers make changes to the file over time, you can diff its 
changes easily.  And when you deploy a release, you'd deploy all the DB objects 
along with the other code.  All other DDL changes (table and column changes) 
would still be regular migrations.

Change Idea:
Since we already have mybatis migrations, it'd be nice to introduce a command 
in mybatis that allows us to execute an arbitrary SQL script.  
e.g. bin/migrate exec objects/compile-all-procs.sql

This seems to be the simplest and most flexible solution.  

Another idea was to add a convention in migrations to look for a certain script 
in some directory (e.g. objects/post-up.sql) and always execute that after the 
migrate up command completed.  That would avoid adding a new command to the 
library, but seems a little too clever and probably has lots of edge case 
problems.


What do you guys think?  I'm willing to code the feature up if you think it 
would be a good fit.

Original issue reported on code.google.com by d...@dantanner.com on 7 Dec 2012 at 4:17