Increasingly, I want to run the 23.x branch and stay no more than a few weeks behind the branch without waiting for a minor release. my hope is that this is more “cloud like”. I also thingk that a few smaller sites running near the edge of 23.x in production makes these branches safer to use and lowers the risk of the minor releases. It also means that when we back merge a fix to a branch these “latest 23.x” servers can help verify the back-ports work.
I have been running servers on 23.x and master now for several years. These are small servers with folks I generally know so little glitches can be quickly handled.
My greatest frustration when I move a server forward along a branch is missing a conversion that was just added to the conversion scripts for the next release of the branch.
So I have built a tool that runs in Sakai and when a simple bit of SQL is added to the conversion script it can be added to Idempotent. That way – without scanning the whole conversion script to see what has and has not been applied – I just Idempotent to check and optionally conversion SQL.
It is cool. It does it all in a servlet – so hot-deploy is super easy. It has a bunch of utility classes to do things like check if a table exists or a column exists or even is a particular but of conversion SQL has already been run.
In the future – I think this needs to be part of Sakai. Ia a person makes a patch that needs a conversion script, (in the future) they would also add a few lines to Idempotent. So if someone did a git pull, recompile, and restart – with a few seconds of startup – all the conversions would be run.
There is a lot of test and work to be done – but I am now running this in production in all my Sakai servers. For now, I will watch the conversion scripts for 23 and 24 and keep my copy of idempotent up to date. Frankly it is easier for me to put the conversion in idempotent than figuring out which ones to apply by hand in the MySQL command line.
I would like to advocate including this in Sakai 24 and 23 – but that will require a bunch of dicussion and take some time. This email is the start of that discussion – here is the source code:
It has a README.md and DESIGN.md.
It is not much code. It could be improved. If this did go into the main repo, I would take some of the bits in the Util class and move them into the SQL service. For now I kept things in idempotent so it would work with any version of Sakai.