Allow running code along side individual migration calls

[seivan]

One of the benefits with Ecto or Active Record is you can run code or even access application code along side the DB migrations.
This is useful if you need to access redis or some other system along side changes occurring in the database.
You also get to piggy back on the DB lock to get idempotent changes.

[weiznich]

That's already possible, although it requires some manual work. You would define some struct that implement Migration and define your custom logic in that implementation. You then pass that via a custom MigrationSource to the connection.

https://docs.diesel.rs/2.2.x/diesel/migration/trait.Migration.html

https://docs.diesel.rs/2.2.x/diesel/migration/trait.MigrationSource.html

[seivan]

That makes it a separate migration though, not conjoin with the migration currently running.
Again, not having migrations to be rust will cause problems if you need to synchronize persistent stores outside of DB with your migrations.

Edit: Not sure if I understood you correctly.
Now I am guessing your intention was that the migrations should all be in structs and implement that trait. That's not a bad idea, I like that. But I just need to know what locking guarantees there are if that's the case.

Assuming I understood you correctly.

[weiznich]

Now I am guessing your intention was that the migrations should all be in structs and implement that trait.

Yes you would have one struct per migration and you could define complete in rust code what that migration is supposed to do as you control the implementation of the Migration::up and Migration::down function.

But I just need to know what locking guarantees there are if that's the case.

By default diesel wraps migrations into transactions for backends that support modifying the schema inside of a transaction. You can opt out that behavior on a per migration basis by using the metadata function and returning the relevant flag there.