Matt Raible wrote:
AFAIK, migrations is simply a bunch of SQL scripts that alters your
database, correct? I major difference is they're smart enough to back
out the changes if anything goes wrong? I believe the reason this
doesn't exist in Java is most Java applications are deployed in an
environment where a DBA handles the database upgrade.
Well, besides being able to back out the changes, it has a standard way
of determining the current database schema version, and applying all the
migrations necessary, regardless of how far behind (or not) the
production environment has become. You always know the same sequence of
migrations will be applied in production as what was tested during
development. You might be right about the DBA driving the database in
most environments w/ Java applications, but I'm working on a COTS app,
so the database schema evolution is completely driven by the application.
For personal deployments, I've often used the following cycle:
1. mysqldump the database
2. run the upgrade script
If #2 fails, drop the database and re-import the dump.
I believe there are some Java tools that've been written to accomplish
Rails-like migrations, I just can't seem to find them ATM on Google.
OK, so I guess there's no no-brainer answer at this point (though I
haven't waited very long for replies yet). Like I said, I'm spoiled by
the development cycle in Rails though, so I'll see if I can find one of
those java tools. If I get one working well, I'll post back and
proselytize it.
- Steve J.
begin:vcard
fn:Steve Jorgensen
n:Jorgensen;Steve
org:Vigilan, Inc.
adr:;;9375 SW Commerce Circle, Suite A1;Wilsonville;OR;97070;USA
email;internet:[EMAIL PROTECTED]
title:Senior Development Engineer
tel;work:503-682-8828 Ext. 226
url:http://www.vigilan.com
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
