Quick question on sql testing/git branch strategy if I may. I’m using next.jdbc/honeysql for building and acting on our database, plus ragtime to apply database scripts to the db in order - all working nicely. One issue I come up with is how to deal with different sql update scripts on git branches. I may have a new script on a certain branch, but need to quickly switch to a different branch for a bug fix or something, and that branch then gets confused when talking to the db because it doesn’t know anything about the already applied script in the existing db that came from the first branch. This is no doubt an extremely common challenge, and I’m wondering if anybody has a battle-tested strategy of dealing with it? Do people have a database per branch, or do people live with manually rolling back and re-applying scripts to get the db into the correct state for the new branch, or what? Any thoughts on this are appreciated as we’re evaluating a few options ourselves right now.

It's a tricky issue, with no easy solution. We manually roll back (I just did one this morning in fact)

You could take a snapshot of the db beforehand and restore, but that may take time etc...

having a db per branch, would mean perhaps your application needs to know how to connect to the branched db

We test all things locally, in a local docker container, so I can destroy it and recreate it as needed without affecting anyone else.

But when we come to do an integration to a shared environment, it's just managed manually, with plenty of heads-up in the communication channels so all devs are aware.

.

it's nice to also maintain db seeds so that when you do tear down and build back up in a new branch you can immediately get a set of useful data

Thanks for the insight. I have it in my head that I could have something in build.clj or somewhere to automatically build a version of the database per feature branch, and dynamically change the db name to that feature branch name (e.g. jsbc:<branch-name> . I would end up with lots of databases but at least you know where you stand as you work on different branches. Maybe the docker container route may work better, as in a separate group of docker containers per branch that spin up and down automatically with a single command. I have that infrastructure ready to go but have been testing locally for a while now as I haven’t really felt the need for the docker environment given the phase of development that we’re at.

you'd have change db ports based on branch, too

may as well use the same db instance but different databases within the db at that point. it would be a lot simpler

Indeed. Thanks for the feedback 👍