Feature request: Adding --dry-run to mix ecto.migrate which only prints SQL statements

[Nick Janetakis]

Hello,

What do you think about introducing a --dry-run flag to mix ecto.migrate which would do nothing but print back all of the raw SQL statements that would have been executed in the migration, but the migration itself wouldn't run.

Of course it's a good idea to test migrations in development and other non-production environments but for the most critical of critical migrations, it might be handy to be able to do a dry run first.

Is this feature pointless or useful?

I'm only requesting it because I happened to see that Laravel (a PHP web framework) has a --pretend flag that does this. I never used Laravel but somehow that tip ended up in my Twitter feed and at a quick glance, it seems like it could be useful feature.

[Gorka López de Torre]

I was looking for this precise feature. There's a `--log-sql` option for the migrate task that dumps the SQL executed for the migration, but I see no way to dump the SQL migration script before actually applying the migration.

In our particular case, we have a high-volume and high-traffic production database for which the wrong migration (columns added in the wrong position, types changed without a proper non-locking strategy,...) could lock tables in the database for hours. We would like to be able to run a `dry-run` migration in the pipeline outputting the SQL that would be executed on the production DB in order for the DB administrator to review the changes and manually approve them before they get applied to the production database.

Nick mentioned Laravel provides this feature through the `--pretend` flag. Doctrine also has this feature with the `--dry-run` option, as Flyway in the Java world does. I believe this feature could not only be beneficial for all, but a requirement for some enterprise level applications where DBA approval for any database changes is a mandatory step towards production. Though theoretically a DBA could examine the Ecto migration files, DBAs I know aren't usually comfortable with (and don't even trust) anything other than SQL.

[Austin Ziegler]

This would also be useful from my perspective, as we use a dependency (Oban) which has some migration management that it does, but one of the environments where we want to use it, we use SQL for migration management (via `sqitch`).

[Parker Selbert]

This would be useful to me personally, and it appears to Oban users / customers in general. I'm willing to do the work on this if it's accepted.

[José Valim]

My concern is that there are commands in migrations, such as Repo.update_all, and those may fail when mixed with a --dry-run. For example, you will try to update it to a version that is not there, because the migration did not effectively run.

--
You received this message because you are subscribed to the Google Groups "elixir-ecto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-ecto...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-ecto/df2c7d0f-9662-41b8-bb3d-f71e6bef76c5n%40googlegroups.com.