Bug#848137: [Dbconfig-common-devel] Bug#848137: problem with the upgrade of tango-db

PICCA Frederic-Emmanuel frederic-emmanuel.picca at synchrotron-soleil.fr
Sat Jan 14 10:12:45 UTC 2017


Hello Paul

> I really hope I can upload this weekend. I have code that I believe does
> what I want. I am in the process of testing it.

thanks a lot.


> [...]

>  What I meant,
> instead of the mysql code that runs as user, run a script for the
> upgrade (they are run with database administrator credentials) and in
> that script do two things: call the DROP PROCEDURES... and then use the
> user credentials to run the normal script.

> Apart from this repair, do you see more use cases? The problem is that
> you would need nearly all the logic that is now in dbc_go for this to
> work. What I am considering is if I could guarantee the order of
> script/user mysql/admin mysql (or the last two reversed). I guess that
> if I would guarantee the script to always come first, it would be easier
> to solve the tango-db issue at hand (which was originally created by
> dbconfig-common).


ok, so If I understand correctl.

In my tango-db postinst, I will add a script 

    /usr/share/dbconfig-common/scripts/PACKAGE/upgrade/DBTYPE/VERSION

which does the fix (drop all the procedures)

then 

dbconfig-common will run my normal

 /usr/share/dbconfig-common/data/PACKAGE/upgrade/DBTYPE/VERSION

script.

right ?

I have more than one version of 'normal' upgrade scripts,

7.2.6
8.0.5
8.2.0
9.2.5

so I need to add the same amount of fix scripts in order to be sure that the database is fixed from the first upgrade.
7.2.6 -> 8.0.5 etc...

I just need to be sure that the database dump is done after the fix except if you run the dump at dbadmin, but In that case I would  have a dump with the non fixed database.


Cheers


Frederic



Paul



More information about the debian-science-maintainers mailing list