← Back to team overview

mythbuntu-bugs team mailing list archive

[Bug 469792] Re: Switch to upstream backup and restore scripts

 

This has been fixed in the trunk packaging.  It will be seen in the next
0.23 autobuilds trunk build available at http://www.mythbuntu.org/auto-
builds.  This bug will be automatically closed when a new build
containing the fix is uploaded to the current development release (Lucid
Lynx).

** Changed in: mythtv (Ubuntu)
       Status: Triaged => Fix Committed

** Changed in: mythtv (Ubuntu)
    Milestone: lucid-alpha-1 => None

-- 
Switch to upstream backup and restore scripts
https://bugs.launchpad.net/bugs/469792
You received this bug notification because you are a member of Mythbuntu
Bug Team, which is subscribed to mythtv in ubuntu.

Status in “mythtv” package in Ubuntu: Fix Committed

Bug description:
Binary package hint: mythtv

<sphery> superm1: I heard you guys are using a *buntu-specific backup script.  What do you think of adding --add-drop-table to the mysqldump options?  Doing so should prevent the issues users are having when they restore a 0.21 schema version backup on top of a 0.22 schema database (the blank one installed by the packages)--which means they end up with 0.22 tables (because of the CREATE TABLE IF NOT EXISTS) with 0.21 data.  (Or if you guys ...
<sphery> ... have a restore script, fix that so it checks to ensure the DB is empty before allowing the restore, like the one in programs/scripts/database does.)
<sphery> I'm considering adding --add-drop-table to the programs/scripts/database/mythconverg_backup.pl script.
<sphery> that way, even if they don't use the restore script, it will prevent issues
* rotorr has quit (Read error: 104 (Connection reset by peer))
* rotorr (n=var@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) has joined #mythtv
* Prost (i=prost@xxxxxxxxxxxxxxxxxxxxxxxxxxx) has joined #mythtv
<superm1> sphery, well I think we are better switching to the upstream backup and restore scripts tbh
<superm1> it's a needless delta currently
<sphery> that would work, too...  My main concern is getting the word out to users--I've seen this happen 4 times, now, and 2 of 3 hacked the schema 'til the upgrade completed, which means their data and schema is likely suspect)