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

[Paul Gevers]

Hi Picca,

On 01/14/17 11:12, PICCA Frederic-Emmanuel wrote:
> 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.

I'll upload in the next hour.

>>  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)

That is the idea.

> then 
> 
> dbconfig-common will run my normal
> 
>  /usr/share/dbconfig-common/data/PACKAGE/upgrade/DBTYPE/VERSION
> 
> script.
> 
> right ?

Officially, no, because the documentation says: "If files exist in both
data and scripts, they will both be executed in an unspecified order."
However, the current behavior of dbconfig-common is to first run the
script and then run the admin code and then run the user code. So you
should be fine (but please test) and I'll make sure this behavior
doesn't change in stretch.

> 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 hadn't realized this, but yes. However, as Debian doesn't support
upgrading from (stable - 2) to stable, you may consider to only add the
fix to the update from the current stable version to the first in
stretch version, i.e. (8.1.2 to) 9.1.0. I don't think it is worth the
reduction thought.

> 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.

Once my fix is in (as said, I expect to upload shortly), I don't think
it is worth it to worry about the unfixed database. The database dump
will be retried with dbadmin credentials when doing it with dbuser
credentials fails.

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20170115/8cda718d/attachment-0001.sig>