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.
"MV" == Maxim Veksler hq4ever@gmail.com 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<
On 08 May 2007 15:30:09 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"MV" == Maxim Veksler hq4ever@gmail.com 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
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
On 08 May 2007 15:30:09 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"MV" == Maxim Veksler hq4ever@gmail.com 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
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.
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.
packaging@lists.fedoraproject.org