Commands in sbt plugin

[lastland]

A prototype which uses sbt plugin to run all the migration commands. Current pros and cons in this prototype are listed below:

• (+) Simple commands. And code responsible for these commands are well separated with the application code.
• (+) Users can override the sbt plugin. This enables users to, for example, use their own migration manager, add their own commands, etc.
• (=) Lots of code are required in project directory, but it shouldn't be a big problem if we provide a template.
• (-) This approach relies heavily on sbt.
• (-) If users change the migration files, they need to reload sbt (because migration files are in the project directory).

[scoutnet-bot]

I agree with your assessment of the pros and cons! Here is a suggestion to reduce sbt dependency heavily and have the migration files not in the project directory:

sbt run runs code from a project, right? Ideally the commands would do something like that. I think the setup needs to be: default migration tool in one sbt sub project. customized migration tool and migrations in another sbt sub project. sbt plugin takes the name of the project containing the migrations and maybe the customized migration manager class name as config values. It calls known methods of the migration manager like sbt's .run calls mains. e.g. like this: https://github.com/slick/slick-codegen-example/blob/b40dfa417eaf77216ebe5df7d2a80dd6f521dd02/project/Build.scala#L34

New commands would have to be implemented by users in the same way. WDYT?

[lastland]

Thanks for your suggestion! I don't like it when users have to create multiple projects to do some (possibly) simple things, but the way you suggest seems to be the best approach (we really don't want our tool to be restricted to sbt). I shall try to experiment on this and we can discuss it in more details after that.

[cvogt]

@lastland fully agree. I like how you are thinking. We are easily on the same page.