[Dbconfig-common-devel] Difficult/partial upgrade

[Vincent Bernat]

OoO La nuit ayant déjà recouvert  d'encre ce jour du mercredi 16 février
2011, vers 23:10, Sean Finney <seanius at debian.org> disait :

> Have you considered using the "script" functionality instead of the
> "file" functionality from dbconfig-common?  


> http://people.debian.org/~seanius/policy/dbconfig-common-using.html/ch-develguide.html#s-updates

I had a  look at it but I  did not understand what kind  of facilities I
can have  in those scripts. If I  have to use "mysql"  command myself, I
don't  exactly see  what benefits  I  have compared  to using  postinst,
except versioning  and ensuring that  dbconfig-common is entitled  to do
the modifications. So, yes, I should  use those scripts but I am missing
some magic trick?

> dbconfig-common doesn't do anything like embedding into a transaction,
> so the changes are applied with no rollback.  basically the SQL is up to
> you, and dbconfig just passes it along to the right invokation of the
> cmdline program to execute it.  so if it fails half way though, it's
> possible that you might be in an inconsistant state.

Well, this means I have some other problems to handle ;-)

>> - if the user later upgrade to 0.5.1+dfsg-2, dbconfig-common will _not_
>> reapply upgrade file for 0.5-1.

> this is correct: dbconfig doesn't keep any state, and leaves that to
> dpkg.  so if the package is at 0.5-1 it assumes it has successfully
> passed all previous upgrades.

At least, this means that users that were able to repair their databases
won't be  annoyed by dbconfig-common  trying to apply old  updates. Good
for me.

>> Therefore,   I   was  thinking   about   just   issuing   "mysql  -f   <
>> $SQL_UPGRADE_FILE" if  the user is upgrading from  something more recent
>> than 0.5-1 and  less recent than the current version.  Is there a better
>> way?

> i'd recommend one of two things:

>  * using the scripting language of the app and writing a small script
> reading the app's database config file, which would allow you a bit more
> flexibility and expressiveness than a shell script, as well as not
> worrying about having to re-generate and handle the configuration.  

Unfortunately, the application  is PHP and I would  have to pull php-cli
just for that.   I could however provide a script  and use a NEWS.Debian
to let the user know that he could use the script.

>  * maybe cheat and call the internal mysql functions of dbconfig
> (dbc_mysql_exec_file, for example) and just slap on an "|| true" to the
> end of it.  that'd *probably* work, though you'd want to test it :)
> consider any function that doesn't start with an "_" to be usable for
> that.  if roundcube supports multiple db types, there's something like
> $dbc_sqlfile_cmd or similar too.

It supports multiple DB but so far, only the MySQL upgrade file seems to
be messed up.

So,  I should  be able  to use  dbc_mysql_exec_file inside  the "script"
functionality, right?
-- 
BOFH excuse #288:
Hard drive sleeping. Let it wake up on it's own...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20110216/a2766d3f/attachment.pgp>