Spring Boot Autoconfiguration and CLI for MyBatis Migrations

[Bessonov]

Hi,

thank you for your work. For my spring application I created an autoconfigration with cli support. I have a lot of questions now.

1. Before I push it to maven central I would like to ask you what do you think about move it to mybatis github organisation?

2. Is there a plan for high level API for commands like script and new?

3. It's an error that pending command can't run migrations without changelog table (even if first script creates the table) and up doesn't pick up old pending scripts?

[h3adache]

Hi @Bessonov . This is nice work! I'll try to answer some of your questions but am not exactly sure what you are asking in some cases:

1. The idea of having each action be an operation was what I did by breaking out the commands which is what I used in previous apps to do runtime migrations. @harawata carried that idea out further to add operations in Support for Runtime Schema Upgrade (i.e. in-app migration) #2 . There was plans to clean some of this up somewhat but .. time. What feature of what you have added would you like to see in migrations? Maybe it can be something added/implemented in the core code itself rather than in another offshoot?

2. Yes there is/was. Look at ScriptCommand and NewCommand. We had discussions in the ticket referenced about where I suggested that we can remove those in favor of the new 'operations' that @harawata introduced but we never did.

3. I'm confused by this comment. version NullPointerException when changelog table is empty #57 is about the pending without changelog table. It's kind of 'as designed' since the changelog table is expected to be created. Are you finding a way that it's not?
   I don't know about the up issue. Can you open a ticket/give us a quick example of what you mean? Pending scripts SHOULD be picked up by up. Otherwise a whole lot of base functionality is broken lol

[Bessonov]

@h3adache thank you for your quick response!

Yeah, I know, my English isn't perfect :(

1. Here I ask if you see it in de.bessonov group and it stay in my repo or in org.mybatis group and your repo.

Basically, what I have done, is usage of Spring Boot capabilities to run in-app migrations and possibility to use produced jar as cli for migrations.

I don't think it is useful in core, because it depends on Spring. But my suggestions would be:

Decouple commands and operations further
That's exactly what you answer in second part. I don't see any possibility to use ScriptCommand as not command line command and it leads to the next point:

Exchange CommandLine.java with command line parsing library.
I see jcommander as a mature and feature rich library. But the main point here is to do command line parsing more reusable. In case of Spring I need a possibility to pass DataSourceConnectionProvider, MigrationLoader, Properties and PrintStream to it, like it works for operations.

Provide utilities to create Change from Filename or string
Because of parseChangeFromFilename is private in FileMigrationLoader.java, I created my own implementation of that.

3. OK, I'll try to reproduce it in a minimal example.

[h3adache]

I actually thought about using jcommander when I was refactoring the options parsing but stayed away from it at the time because it was pretty new at the time and more importantly, I was trying to stay with the theme that we don't introduce too many external dependencies. If you look we currently only depend on mybatis (and of course any of it's transient dependencies).
That decision now seems a bit limiting as migrations has it's own scope and use.
If that ends up being the direction we go, it won't be until we refactor the options/commands further as you mentioned earlier.

[harawata]

Interesting idea.
I didn't think of a use case that someone performs various commands other than 'up' once the product is released as a JAR file (the JAR may not run correctly with an older version of the DB schema, right?).
May I ask who uses the migration commands in your scenario?

[Bessonov]

@h3adache reduce external dependencies is right way to go. I can imagine to split mybatis migrations core (executor) from mybatis migrations cli (runs executor). So you can have both: reduced dependencies and reduced code for cli. And I can use both in my autoconfiguration.

@harawata of course you can :) I support a little start-up and we switch now from liquibase to mybatis migrations. There some workflows, which we would like to implement:

1. Usage of maven for new script creation and work with a local database. There is no place for production.properties
2. Usage of executable (and self-containing) jar to run in-app migrations (up only) in production
3. Usage of executable jar to perform automated integration testing with this jar (up, down, version)
4. Usage of executable jar to perform migrations which involve multiple steps with external systems (up --steps=1)

On other side I know companies, which have different teams for development and database migrations. Output of script command from self-containing jar would be useful for them.

the JAR may not run correctly with an older version of the DB schema, right?

It depends. I assume always a developer know what he/she doing and don't expect working app if needed table doesn't here.

For example with galera cluster schema can be migrated with zero downtime. But with RSU nodes must be migrated one by one.