Upgrading databases as part of the RPM postinst script?

[Maxim Veksler]

Hi list,

As part of the software (binaries) upgrade process my rpm will need to
update database scheme (and possibly some configurations data) inside
a mysql database.

Are there any recommendations or case studies I should follow to screw
things up as little as possible ?

Thanks and happy hacking,
Maxim.

-- 
Cheers,
Maxim Veksler

"Free as in Freedom" - Do u GNU ?

[Jason L Tibbitts III]

> >>>> "MV" == Maxim Veksler
> <hq4ever(a)gmail.com&gt; writes: 
MV> As part of the software (binaries) upgrade process my rpm will
MV> need to update database scheme (and possibly some configurations
MV> data) inside a mysql database.

I would recommend not even attempting to do that kind of thing.  How
do you know the database is running at the time, or even that it's on
the same machine?

 - J<

[Maxim Veksler]

On 08 May 2007 15:30:09 -0500, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
>  >>>>> "MV" == Maxim Veksler
> <hq4ever(a)gmail.com&gt; writes:
>
>  MV> As part of the software (binaries) upgrade process my rpm will
>  MV> need to update database scheme (and possibly some configurations
>  MV> data) inside a mysql database.
>
>  I would recommend not even attempting to do that kind of thing.  How
>  do you know the database is running at the time, or even that it's on
>  the same machine?
>  
I check, or ask the user.

I think that my questions is more of "how to do this" then who/when to
do this. I think we can agree that if my databases changes between
version and I wish to allow my users to continue running with their
existing data I need to provide some method for them to upgrade their
scheme while not loosing their data.

Pointers on the above would be very welcome.
Thank you.

>   - J<
>
>  --
>  Fedora-packaging mailing list
>  Fedora-packaging(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-packaging
>  

-- 
Cheers,
Maxim Veksler

"Free as in Freedom" - Do u GNU ?

[Ray Van Dolson]

On Tue, May 08, 2007 at 11:35:46PM +0300, Maxim Veksler wrote:
>  >I would recommend not even attempting to do that kind of thing. 
> How
>  >do you know the database is running at the time, or even that it's on
>  >the same machine?
>  >
>  
>  I check, or ask the user.
>  
>  I think that my questions is more of "how to do this" then who/when to
>  do this. I think we can agree that if my databases changes between
>  version and I wish to allow my users to continue running with their
>  existing data I need to provide some method for them to upgrade their
>  scheme while not loosing their data.
>  
>  Pointers on the above would be very welcome.
>  Thank you.
>   
Perhaps providing migration/conversion/update scripts as part of your
new RPM that the user is then instructed to run manually?

I guess this could potentially mean things won't work correctly if the
udpate happened automatically and the user wasn't around.

Ray

[Jason L Tibbitts III]

> >>>> "MV" == Maxim Veksler
> <hq4ever(a)gmail.com&gt; writes: 
MV> I check, or ask the user.

You can never ask the user; packages cannot be interactive.

 - J<

[Ville Skyttä]

On Tuesday 08 May 2007, Maxim Veksler wrote:

>  I think we can agree that if my databases changes between
>  version and I wish to allow my users to continue running with their
>  existing data I need to provide some method for them to upgrade their
>  scheme while not loosing their data. 
Note also that schema updates are operations that people generally want to do 
only after making a full backup of existing data, so that they have something 
to return to in case something goes south with the update, or if the new 
version does not for one reason or another meet their needs and they want to 
downgrade.  Upgrade scripts that upgrade the schema but leave it in a 
backwards compatible state are to some extent safer (and rarer), but I 
wouldn't be happy to see them being run automatically from package scriptlets 
either.

[Gianluca Sforna]

On 08 May 2007 15:30:09 -0500, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
>  >>>>> "MV" == Maxim Veksler
> <hq4ever(a)gmail.com&gt; writes:
>
>  MV> As part of the software (binaries) upgrade process my rpm will
>  MV> need to update database scheme (and possibly some configurations
>  MV> data) inside a mysql database.
>
>  I would recommend not even attempting to do that kind of thing.  How
>  do you know the database is running at the time, or even that it's on
>  the same machine? 
That is quite the same situation I am facing right now with mantis: in
older releases, users was forced to browse a specific page to update
the schema.
Now I proposed upstream the addition of a script for performing the
same updates from the command line, so I could add it in a scriptlet:
of course it could fail for many reasons, but if you have a working
installation then the configuration files has all the information
required to connect to the database.

I don't know if a similar solution is applicable at all in your
situation, because it mostly depends on how the schema update is
implemented upstream

[Nicolas Mailhot]

Le Mer 9 mai 2007 10:28, Gianluca Sforna a écrit :

>  Now I proposed upstream the addition of a script for performing the
>  same updates from the command line, so I could add it in a scriptlet:
>  of course it could fail for many reasons, but if you have a working
>  installation then the configuration files has all the information
>  required to connect to the database. 
This kind of script is very dangerous to run from a scriplet,
especially if the operations behind are not designed to be run
unattended or output info that must be checked by the admin.

Even if it works most of the time, if there is a significant risk of
total or partial failure (the real dangerous one) it should not be
scriplet-run. Getting updates to work across version jumps (someone
updating directly from Fx to Fx+2) is also tricky in a scriplet
context. You'll almost sure to hit someday a version jump or a local
database customization upstream forgot to check.

-- 
Nicolas Mailhot