Martin,
I see your pointn and I agree that it's in general not simple.
Only, I don't quite agree that it is the same for internal development.
If the monetdb developers change one of the built-in functions, and this
needs a new SQL signature, they will use the upgrade facility to patch the
database at the next start, automatically. And that's crucial, because
otherwise the functionalities of the server would be broken, regardless of
what data and what application uses them.
For UDFs, there is nothing like that. Unless you patch a database manually,
you are going to break the server functionalities.
We did without this till now, we can live without for longer, no big deal.
But it is a missing feature, that's all.
On Wed, 22 Apr 2020, 21:29 Martin Kersten,
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
On 22/04/2020 19:52, Roberto Cornacchia wrote: 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.
instead of just half-way and then having to patch it with some external
Not application data. I seems only normal to me to be able to upgrade that code completely (i.e. including the correct SQL signatures), 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.
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list