dbmigrations
dbmigrations copied to clipboard
jtdaugherty
Running migrations from within server
I've sort of touched on this idea before, but now I'm quite certain this would be nice. Instead of having to run a separate program in order to run my migrations, I'd like to capture all my migrations directly in source code and then run them within my server process. I'm imagining (though I might be wrong) that this would make a zero downtime deploy much easier. Perhaps I'm wrong, in which case I'd love to hear how you do it.
Welcome back. I recall that you opened #27, which eventually got closed due to inactivity (rather than opposition). As far as I'm concerned dbmigrations is still capable of doing what you want, although some minor modifications are probably necessary. I don't have time to make them myself, but I would be happy to collaborate with you on a plan of attack if you're interested in making the necessary changes.
I'm also interested in this use case. Actually, I'm already doing this, here is the snippet that executes all outstanding migrations at app startup: https://gist.github.com/basti1302/f57efbd6e987705ab698fb9be22d4502
This uses Moo's configuration mechanisms, (that is, moo.cfg if present) to configure the path to the migration store etc. but my app's configuration mechanism to figure out the PostgreSQL connection string etc.
Granted, there might be room for improvement here.
For one, this seems like quite a lot of code to achieve the goal; maybe dbmigrations could make it easier somehow? I'd like @jtdaugherty input on this.
Second, for purely aesthetic reasons it feels a bit odd that this code uses stuff from Moo, ideally, it only should need stuff from Database.Schema.Migrations. I'm not 100% sure, but I think this should be possible when the changes from PR #32 have been published (with the exception of reading moo.cfg, maybe, but it's okay if importing Moo modules is required for that).
Last but not least, this use case and how to achieve it should be documented in the README so people know it is supported and don't have to figure it out themselves.
@3noch Could something similar to the gist I posted also work for your use case? What are you missing?
@basti1302 judging by this,
I'd like to capture all my migrations directly in source code
I think @3noch intends to literally keep the migrations in his program sources rather than loading them from a filesystem directory. Is that right, @3noch?
If that's right, then dbmigrations doesn't support that yet because only the Backend is passed to the library at startup time; we'd need to make it so that a MigrationStore is passed, too, and then there'd need to be a MemoryMigrationStore or something that just wraps haskell data structures containing the migrations.
@jtdaugherty Yes that's correct. Putting the migrations in files is half decent...but it's just more "stuff" that my app needs to carry around. I'm currently playing with https://github.com/MichaelXavier/drifter-postgresql which is a very stripped down tool that allows for this.
@3noch Okay. Is this something you're interested in contributing? Or would you prefer that someone else take care of this?
Then @3noch's use case is different from mine. Sorry for hijacking this thread ¯_(ツ)_/¯
@basti1302 Actually you're pretty close to what I want. I mainly want to run migrations from within my server executable instead of in another tool (like moo). As additional bonus I'd just like to embed the migrations in the source purely for convenience.
@jtdaugherty I'm really just exploring at this point. Drifter doesn't have the idea of rollbacks for each migration and I'm not sure if that's a problem or not. My use case is actually pretty small so I doubt I'll need the full power of dbmigrations anytime soon.
I created this issue partly as a way of probing how others solve the migration problem or if someone was already running the migrations directly in their server (which @basti1302 seems to be doing) via dbmigrations. It appears that most people are happy with the current setup of running moo though.
From what I can tell, it seems that dbmigrations' approach is properly suited to serious server setups where you are likely to have multiple DB servers that can end up with different schemas and need paths to a common HEAD. In this case your DB is likely distributed and it's not nearly as useful to run your migrations from within your web server. For this, moo is likely the right tool.
My use case is much simpler and really just needs to a more powerful version of persistent's migrateAll function. I think drifter is better suited to this simple case at this point.
Now, I still think it would be cool if dbmigrations could support use cases on both sides of the spectrum. But I don't think my needs are strong enough to justify reworkingdbmigrations to support it myself.
If I'm wrong about any of this I'd love to be corrected!
From what I can tell, it seems that dbmigrations' approach is properly suited to serious server setups where you are likely to have multiple DB servers that can end up with different schemas and need paths to a common HEAD. In this case your DB is likely distributed and it's not nearly as useful to run your migrations from within your web server. For this, moo is likely the right tool.
dbmigrations wasn't designed to be on a particular side of the coin you're describing. But as I've mentioned before, dbmigrations can be modified to accommodate your use case without too much trouble. That's exactly why it's implemented as a library.
Since this package is no longer maintained, I'd like to mark the GitHub repository as read-only. I'm closing this ticket as part of that change. This package is now marked as deprecated on Hackage; see the maintenance note in the README if you're interested in taking over maintenance.