Ability to render migration steps as sql script

[DavidPavlicek]

Hi, first of all thank you for this awesome piece of SW. I start using yuniql recently and I'm pretty impressed with what it offers. But I'm missing one feature which is the ability to render migration scripts to a single file (or stdout). Exactly how is rendered with --debug option but without app trace, only pure SQL and for specified versions (optional min/max).

[rdagumampan]

@DavidPavlicek Thanks a lot for your feedback and interest with yuniql. I will take sometime to investigate this. The feature seems easy to support if we implement a new traceService.DebugScript and maybe some --trace-level sql. Can you explain what is your use case why you prefer to leave out the debug logs?

[DavidPavlicek]

@rdagumampan In my case (Postgresql developer/DBA), I have at least 2 use cases:

• Automating the process of building PostgreSQL extension from yuniql migration project. PG extension has a series of extension-version.sql scripts executed in sequence by version number. But in yuniql, each version is represented by multiple folders/files. If yuniql will have a command to squeeze in all version files into one SQL file, it should be easy to automate this process. For me, developing new extensions/projects is much more pleasant in yuniql because of project organization.
• There are a lot of strict environments where you are not allowed to install uncertified software or even connect remotely to a database (from an untrusted computer). In such cases, migrations are performed by manually executing migration scripts from SQL files. In some cases, you are not even allowed to copy and execute files. Then you have to send files to security staff, they reviewed your scripts and execute them on their own. In such cases, it will be beneficial to have one file per version, instead of a bunch of folders/files.

Hope that explains my main motivation behind this issue. I think there are plenty more use cases to have one compiled script for each version or series of versions. And as I wrote this, I'm thinking that compile subcommand will be a good match for this ;)

[prodigy]

@rdagumampan In my case (Postgresql developer/DBA), I have at least 2 use cases: [...]

• There are a lot of strict environments where you are not allowed to install uncertified software or even connect remotely to a database (from an untrusted computer). In such cases, migrations are performed by manually executing migration scripts from SQL files. In some cases, you are not even allowed to copy and execute files. Then you have to send files to security staff, they reviewed your scripts and execute them on their own. In such cases, it will be beneficial to have one file per version, instead of a bunch of folders/files.

[...]

That's exactly our usecase too as we are investigating tools to perform migrations in strict environments, but have the ability to automatically perform migrations in our own development/test environments.