Support for Runtime Schema Upgrade (i.e. in-app migration)

[harawata]

The goal is to provide a flexible and easy-to-use API for java programs that need migrations at runtime.
The API should provide:

1. a way to pass DataSource for database operations.
2. a way to read migration scripts from inside JAR.

The targets of this issue is the following database operation commands.

• bootstrap
• up
• down
• status
• version
• pending

This was originally reported as mybatis/old-google-code-issues#653

[h3adache]

I like the general idea of the changes.
The operations seem to be a completion of what I started with splitting out the commands.
But otherwise, they seem to be the same thing. I wouldn't keep the commands around if you have the operations, it's just another layer/wrapper.

[harawata]

Hi Tim,

Thank you for the input!

Command is actually an important layer that translates command line args/settings into values being used in Operation (= Java API) layer.
Each Command class could look a little bit redundant, but that may be because its parent BaseCommand does the heavy lifting mostly.

Wouldn't you agree that we should keep those command line stuff out of Java API layer?

Best regards,
Iwao

[h3adache]

I do agree with keeping that out. That is why I added the options/options parser and the commands enum.
The thought is that you can construct the commands directly or using the commandline "api".
It looks like you are carrying this thought out even further with option but it's really the same separation of concern that I had. So I would say just get rid of the commands and stick to options (or visa versa). It keeps it more light weight.
My redesign plan for migrations "ng" (ie 4) would have been to redesign the whole framework starting from individual commands up. The options/string parsing would then be just a translation layer above it.

[harawata]

Ah, I see. Sorry about my misunderstanding.
With your plan, Maven plugin, Gradle plugin and the built-in command line client will use the Java API, is that correct?
I vaguely imagined the same thing for the next major version as well.

But it requires a lot of work including rewrite of the existing clients.
So, I thought it would be better to have an intermediate version in 3.x which keeps the existing clients intact[1] and provides usable Java API at the same time.
Does it sound reasonable or should we move to the 'ng' version already?

[1] the maven plugin needs some adjustment as it uses some internal stuff.

[h3adache]

Yes! That is/was the plan. Sorry I've been lazy and haven't been working on
it.
This will make all those interfaces simply wrappers on top of the java API.
It simplifies their development and makes it so that we can define an API
and change internals without worrying about keeping those up to date.
Yea I don't think we need to stop work on the 3.x client.
Thanks Iwao!

On Thu, Jul 11, 2013 at 9:45 AM, Iwao AVE! [email protected] wrote:

Ah, I see. Sorry about my misunderstanding.
With your plan, Maven plugin, Gradle plugin and the built-in command line
client will use the Java API, is that correct?
I vaguely imagined the same thing for the next major version as well.

But it requires a lot of work including rewrite of the existing clients.
So, I thought it would be better to have an intermediate version in 3.x
which keeps the existing clients intact[1] and provides usable Java API at
the same time.
Does it sound reasonable or should we move to the 'ng' version already?

[1] the maven plugin needs some adjustment as it uses some internal stuff.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-20816447
.

[harawata]

Tim,
I know you had spent much on optimizing the code, so I thank you!
As we're expecting 3.1.1 release soon, I've set the milestone of this issue to the next minor release.
Best regards,
Iwao