On 22/04/2020 19:52, Roberto Cornacchia wrote:
Hi (the other) Martin,
Thanks for that input.
If I understand well though, I think we are not talking about the same type of upgrade.
I'm not upgrading data/schemas of an application. With a new release I'm possibly upgrading internal C and MAL code.
Our experience in changing code on a daily basis at that level has told us that there is just no silver bullet. Manual intervention is often needed to resolve conflicts between branch merges when it concerns C, MAL or even SQL syntax changes. Let alone running extensive testing to check-out for collateral damage. The situation you describe is similar to taking our latest code branch and merging it with your enhanced older version. You have to bite the bullet yourself. The same holds for upgrading the running instances on the old code base, but at least that can be orchestrated by temporarily stopping the server, possibly with a fail-over instance to step in temporarilly. This is typically an upgrade script to avoid manual interaction. Sorry. Not application data. I seems only normal to me to be able to upgrade that code completely (i.e. including the correct SQL signatures),
instead of just half-way and then having to patch it with some external scripts.
I've actually done that part for our own scripts, without any location issue, OS assumption or security risk, and reusing code already available.
I understand if this is not the solution that you'd prefer in general for MonetDB, but whatever the solution is I do still think that the issue is real and should not rely on some external scripting. When starting a database with a new release, regardless of any application, it should be consistent and correct. Now it isn't.