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