Migration hook

[dullbananas]

When running diesel migration run or diesel migration revert, if migrations/hooks/before_all.sql exists, it should be executed once at the beginning, before migrations are run or reverted. The use case for Lemmy would be to have a hook that drops a temporary schema (it has functions, triggers, etc. that are recreated after the run_pending_migrations call when running lemmy_server) to ensure a consistent state that the migrations are run with. If this feature is added, I'm pretty sure Lemmy will no longer need to have a custom migration CLI.

[Nutomic]

Note that this functionality is already implemented in Lemmy, ideally it can be upstreamed into diesel_cli.

LemmyNet/lemmy#4673

[weiznich]

Thanks for opening this discussion.

From what you describe that seems to be pretty specific needs for your project. I would rather not add project specific functionality to diesel itself, but I'm open to consider more abstract functionality that could enable this if there is more than one project looking for something like that.

That written: Outside of diesel-cli diesel also provides the diesel-migration crate which is specially designed for situations where the basic CLI tool is not enough. It allows you to easily build your own customized migration process by exposing basically very diesel-cli internally does with different levels of abstraction.

[Nutomic]

Its not so specific, what it does is provide a file to define database triggers which gets applied after all the migrations. By default diesel makes this rather complicated, if you add a db trigger in a migration and change it later, you have to copy the whole definition to a new migration file. After a while it gets very complicated to figure out which triggers exist and where they are defined. With this implementation they are all defined together in the same file.

[weiznich]

This seems to contradict what was written in the OP as that mentions a before_all sql file, which seems to be executed before any migration is execute. Would it be possible to provide an exact description on what you want to implement, how this would look like and why this isn't already supported by the various traits and methods provided by diesel_migrations?

As for being specific: So far only lemmy has asked for this, so even if that's a more general mechanism nobody mentioned needing it for all the years diesel does now exist. For me that still sounds quite specific therefore.

[Nutomic]

Yes he wrote it a bit unclear. What we have are two files called replaceable schema which define various sql triggers and functions which are part of schema r. Now before a migration runs, the r schema is dropped, and afterwards the replaceable schema is applied again. This is all implemented using diesel_migrations. However it means that we cant use diesel_cli to run migrations.

[weiznich]

As written before: I'm not completly opposed to this, but I would like to see a full detailed proposal first on how exactly this is supposed to work including some details on how we communicate that to users.