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, <martin@monetdb.org> wrote:
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.
>
_______________________________________________
users-list mailing list
users-list@monetdb.org
https://www.monetdb.org/mailman/listinfo/users-list