[mythtv] Ticket #4760: Use a script for the database backup

Michael T. Dean mtdean at thirdcontact.com
Mon Mar 10 03:12:35 UTC 2008


On 03/09/2008 09:15 PM, Nigel Pearson wrote:
>> I'm not sure what you mean by "requiring an installed script
>> to circumvent an accidental upgrade".  If there is no script,
>> the upgrade is allowed to continue
>>     
> Sure, but at the moment it _also_ generates a backup.
> Even if I run ./programs/mythfrontend/mythfrontend
> without having done make install first.
>   

Ah...  Gotcha.

>> this brings me to something I was thinking about the other day.
>> We currently enable automatic schema upgrades for the backend or
>> mythtv-setup when we determine the user is running myth* in an
>> non-interactive shell.  If the idea is to prevent accidental upgrade,
>> this could easily fail.  If, however, we included a "-u" argument,  
>> as in
>> mythfrontend, then the user can choose to put it in start scripts (and
>> bear all responsibility for accidental upgrades) rather than our
>> assuming they want to upgrade since the shell is non-interactive.
>>     
> 1) Agree that non-int.-auto.upgrade is bad.
> I only coded the  to keep the current behaviour.
>   

Yep.

> 2) Running mythtv-setup in a non-interactive shell
> shouldn't matter. If there is no GUI, MythContext
> will never get created, and the upgrade will not happe,
>
> 3) Having mythbackend -u seems reasonable.
> (but in the interests of reducing
>   un-necessary command-line args,
>   why not just set DBSchemaAutoUpgrade=1)
>   

I was thinking the argument would leave us closer to 1) because with the 
DB setting, a user would have to either run mythtv-setup/mythbackend 
interactively or directly edit the DB to get the initial DB update 
(yeah, users probably /should/ run mythtv-setup/mythbackend 
interactively once when first installing Myth, but...).  With a 
command-line arg, a user could decide at the command line (i.e. when the 
first attempt at starting mythbackend through a SSH session exits 
logging the error, "Your database schema needs updating.  If you would 
like MythTV to upgrade your database, please re-run the program with the 
-u argument.  <this cannot be un-done, ...>").

Besides, having -u in mythtv-setup and mythbackend would make them more 
symmetrical with mythfrontend (which now has a -u argument).  It got a 
-u argument in the DB schema version check change (from #4625).

It's really not that big a deal.  As you said, now it's basically how it 
used to work, but we have an extra sanity check for those running 
interactively.

>> BTW, you can find a copy of the current backup script at
>> http://misc.thirdcontact.com/MythTV/database_mythconverg_backup.pl
>>     
> % perl ~/Desktop/database_mythconverg_backup.pl
> Unquoted string "gzip" may clash with future reserved word at /Users/ 
> nigel/Desktop/database_mythconverg_backup.pl line 689.
> String found where operator expected at /Users/nigel/Desktop/ 
> database_mythconverg_backup.pl line 689, near "gzip
>                      "$backup_conf{'directory'}/$backup_conf 
> {'filename'}""
>          (Do you need to predeclare gzip?)
> syntax error at /Users/nigel/Desktop/database_mythconverg_backup.pl  
> line 689, near "gzip
>                      "$backup_conf{'directory'}/$backup_conf 
> {'filename'}""
> Execution of /Users/nigel/Desktop/database_mythconverg_backup.pl  
> aborted due to compilation errors.
>
>
>
> Changing the line to:
>               $result = new IO::Compress::Gzip
> gets past it, but I don't know what it does
> on machines with that module installed.
>   

Oooh.  Double thanks for testing that.  It seems my, "check for the lib, 
but don't require it code" isn't quite there--all my systems have the 
module installed.  I'll set up a system without it so I can do some 
further testing.

> (OO-perl is still an un-natural beast to me)

Agreed.

Mike


More information about the mythtv-dev mailing list