[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