Tbh I fail to see how a release with some module to run migrations doesn’t essentially give you that. If you want to just run migrations do
bin/app eval SomeModule.run_migrations. If you want to run migrations on boot you can put the same call in a boot phase or withinMyApp.Application.startand it’ll be run on boot.The complex part will be within
SomeModule.run_migrationsand depend on the project being built.
Can you flesh out this part please?
Near as I can see we are all proposing a core bit of code “SomeModule.run_migrations”. The discussion is going slightly sideways, but I’m essentially pondering who/what/when kicks this module off?
In mix land we can use a mix task. In release land we seem to need “eval” to kick it off. I’m basically proposing to upgrade it to a genserver and stick it in the app tree (which I don’t see as a million miles away from using an eval?)
Main issues I’m struggling with are how to "compose"migrations from multiple parts of an umbrella. In one of my projects I have optional apps included within an umbrella and these use a variety of DBs and hence multiple migrations, potentially scattered across the app and different for different builds. Presumably you are arguing in favour of using each individual Apps Application.start function?
Calling a fixed module from MyApp.Application.Start, or inserting the same code into the OTP tree seem very similar to me? The idea of using the OTP tree is that I could in theory decide to cascade failure or not… I don’t feel very strongly about this since it seems a bit nuanced for most use cases. However, given that if I don’t start up then I lose control over the whole box (not UI to have a user install a fixed firmware, no background service to allow an automated admin tunnel..), then it’s essential that I can try and ignore failures or take appropriate action (eg at least one repo is just logging data, so we can afford to blow that away to get back into a sane state.)
I’m also a bit unclear what happens if we have an umbrella app and one of the apps wants to fail it’s startup due to a failed migration? I guess it’s not so different if we fail in our OTP tree than the Application.start function? Will depend whether we set the app to :permanent? I guess I was thinking that putting it in the OTP tree gave me a bit more flexibility on when and how to fail (or ignore an error)
It seems to me that a web app might also want to struggle partly into life and offer some diagnostics to the user on how to rectify the failure? Dunno?
Note though that if YOU are automatically running migrations at app boot then we are already on the same page. What I’m basically advocating is that apps should move towards automating all (where practical) migration tasks and assisting the user in managing this process. Sure - offer me some advanced commands if it’s useful for me to run the migrations separately to booting the app, however, if migrations need running then don’t let me boot the app without running them! Fail, warn, disable functionality, whatever, but do everything possible to avoid involving me! (meaning for sure, don’t lose data, but if it’s case of running “Blah.run_migrations” then get on with it…!)
Thanks for taking the time to reply! Appreciated.
