[mythtv] mythtv commit: r15901 - in trunk/mythtv/libs by cpinkham

[Chris Pinkham]

* On Mon Feb 11, 2008 at 09:25:46PM +1100, Nigel Pearson wrote:
> > Log: Add code to backup the database before any schema upgrade.

> Just tried Mac frontend and was surprised by a
> DBUtil ... mysqldump error (in fact. I'm amazed
> that my Mac had mysqldump in its path :-)

I thought about Win32, but unfortunately didn't think about Mac until
an hour after I committed.

> 2008-02-11 16:40:32.512 SG(Default) Error: FindNextDirMostFree: '/ 
> myth/tv' does not exist!
> 2008-02-11 16:40:32.513 Backing up database to file: /myth/tv/ 
> mythconverg-1208-20080211164032.sql.gz
> sh: line 1: /myth/tv/mythconverg-1208-20080211164032.sql.gz: No such  
> file or directory
> mysqldump: Got errno 32 on write
> 2008-02-11 16:40:32.720 DBUtil Error: Error backing up database:  
> mysqldump --defaults-extra-file='/tmp/mythtv_db_backup_conf_nkYIFL' -- 
> host='149.135.128.77' --user='mythtv' --add-drop-table --add-locks -- 
> allow-keywords --complete-insert --extended-insert --lock-tables --no- 
> create-db --quick 'mythconverg' | /usr/bin/gzip > '/myth/tv/ 
> mythconverg-1208-20080211164032.sql.gz' 2>/dev/null (1)
> 2008-02-11 16:40:32.723 Unable to backup your database.  If you have  
> not already created a backup, you may want to exit before the  
> database upgrade and backup your database.
> 
> 
> 1) GetBackupDirectory() should check directory exists?

Saw your commit, thanks.

> 2) Calling BackupDB() before PromptForSchemaUpgrade()
> means backup is always attempted if the schemas differ,
> but has the disadvantage of needlessly doing a backup
> (e.g. user selects "Use Existing Schema" or Exit,
>   or DB schema is newer than the connecting client?)

I think that in these cases, we want to make sure there was a
backup.  If the user is running a program that expects a newer or
older DB version than the current one, we have no guarantee what
corruption may or may not occur.  Having a backup done before the
user does this sounds like a good idea.  The backups don't take
that long to run, mine only took 19 seconds with a remote DB.  I
think sphery said his were taking about 29.  I can see adding a
hidden setting to disable DB backups for dev machines, but if
someone is running a different schema version than their binaries
expect, a backup should almost be a requirement.

With the other commit that I made after this backup one, by default
you can't run mythbackend, mythtv-setup, or mythfrontend on a DB
that has a newer schema than what the program expects.  The only
way around this is by turning on the pre-existing hidden setting to
enable expert mode.  Maybe the solution is to not run backups if expert
mode is enabled or perhaps do not run if expert is enabled and
the schema version is newer than expected.

We could just call PromptForSchemaUpgrade() first and check the
result, and then only run the backup if the user selected to
run anyway or to upgrade the schema.


int upgradeCheck =
        gContext->PromptForSchemaUpgrade(dbver, currentDatabaseVersion);

if (((upgradeCheck == MYTH_SCHEMA_USE_EXISTING) ||
     (upgradeCheck == MYTH_SCHEMA_UPGRADE)) &&
    ((gContext->GetNumSetting("DBSchemaAutoUpgrade") != -1) ||
     (CompareTVDatabaseSchemaVersion() < 0)) &&
    (gContext->GetNumSetting("DBSchemaBackupBeforeUpgrade", 1)))
{
    if (!dbutil.BackupDB())
        VERBOSE(VB_IMPORTANT, "Unable to backup your database.  If you have "
                "not already created a backup, you may want to exit before "
                "the database upgrade and backup your database.");
}

switch (upgradeCheck)
{
        case MYTH_SCHEMA_USE_EXISTING: return true;  // Don't upgrade
        case MYTH_SCHEMA_ERROR:
        case MYTH_SCHEMA_EXIT:         return false;
        case MYTH_SCHEMA_UPGRADE:      break;
}

That is untested, but should only backup the DB if (we are going to upgrade
it or we're running a different binary schema version than DB schema version)
AND (we're not in expert mode or we're running an older schema with newer
binary).  You could also set DBSchemaBackupBeforeUpgrade to 0 to prevent
DB backups on a dev system.

Does that handle what you're looking for?

--
Chris