[mythtv] Schema updates

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Mon Mar 5 05:20:32 UTC 2007


I just had an idea.  Does this trip over any constraints I'm not aware of?

Goal:  Prevent accidental schema upgrades, without "getting in the
way" of deliberate ones.

What's a "deliberate" schema upgrade?
(a) New MBE---must upgrade.  [With a wrinkle: see note 1.]
(b) New FE in an FE -only- install (e.g., no MBE anywhere).  Must upgrade.

IMO, any other scenario is an "accident" and we either query or
proceed, depending on the settings of some switches.  In particular:
(a) New SBE---fail with copious logging.  (No UI to enable a query.)
(b) New FE or mythtv-setup---query or proceed.

We add two new settings to the DB, in the "settings" table:

ThisDatabaseSawAnMBE, with values:
  Yes
    An MBE has run at least once, using this database.  Therefore,
    it's not an FE-only installation.  (MBE's unconditionally set
    this flag when they boot.  Question:  What should SBE's do?)
  No   [initial setting]
    This database has never seen an MBE.  Therefore, it's an FE-only
    installation.

SchemaUpgradeSafety, with values:
  ProceedAlways
    Always upgrade no matter who (FE, SBE, MBE, mythtv-setup) is the
    new guy.  This is the most dangerous setting.  This is equivalent
    to how myth behaves right now.  SVN users will probably decide to
    set this pretty quickly, but if they always upgrade their MBE
    first, they could leave it set to ProceedIfMBE and not notice.
  ProceedIfMBE   [default? see note 1]
    If ThisDatabaseSawAnMBE is Yes:
      If this is the MBE, just upgrade.  Otherwise, behave as if
      AskAlways is set.
    If ThisDatabaseSawAnMBE is No:
      Act as if ProceedAlways is set.   [see note 1]
  AskAlways   [default? see note 1]
    Always ask if you have a UI (FE, mythtv-setup).  Fail with copious
    logging if you don't have a UI (MBE, SBE, <anything else?>).

[Note 1: I'm not sure if saving the user from an accidental -MBE-
upgrade is worthwhile (like, say, a yum/apt/whatever run that got out
of control).  If it is, AskAlways should be the default.  If it's not,
ProceedIfMBE should be the default.  Similarly, in an FE-only
installation, do we save the user from an accidental upgrade there?
Same question.]

What's the UI for this like?

If ProceedAlways is set, you don't see anything ever.

If ProceedIfMBE is set & you're an MBE, you don't see anything ever.

If ProceedIfMBE or AskAlways, and you're an FE or you're mythtv-setup,
you display something like

  This version of mythfrontend/mythtv-setup expects database revision
  12345, but your master backend (at IP address 1.2.3.4) expects
  revision 9975.  That means your backend is older than this frontend,
  and may not function correctly until it's been upgraded.  It is
  recommended that you upgrade your backend -first-.  If you still
  wish to proceed, you can upgrade the database your backend is using
  right now, but it still might not work right because your old
  backend will be seeing a newer database.  Do you want to:
     Quit (and either go upgrade your backend, or downgrade your frontend)
     Make a backup of your database, then come back to this point
     Upgrade the backend, but ask me this again if I run a newer
       frontend later 
     Upgrade the backend, and automatically upgrade the backend in the
       future at every opportunity, without ever asking me again [not
       recommended unless you run the SVN releases]
  Please note that if you answer UPGRADE, it is NOT possible to undo
  this!  From that point onward, you must use this frontend or any
  newer version, but not the frontend that was running revision 9975.

[Obviously, selecting the first Upgrade option leaves SchemaUpgradeSafety
alone, but the second one bashes it to ProceedAlways.]

If you're an SBE and ProceedAlways is NOT set, you "fail with copious
logging", e.g., you send this to stderr and syslog:

  This slave backend (at IP address 5.6.7.8) expects database revision
  12345, but your master backend (at IP address 1.2.3.4) expects
  revision 9975.  That means your master backend is older than this
  slave backend, and this slave may not work correctly until the
  master has been upgraded.  If you actually intend to run this new
  slave, please install a newer version of your master backend.  If
  you'd like to live dangerously and run this slave without installing
  new master backend code, but upgrading its database out from under
  it anyway---knowing that the master expects a different DB schema
  and thus might break if you do this---run mythtv-setup and let it
  upgrade your master backend's database schema.

I'm not in love with the phrasing of these warnings, especially the
second one.  Part of it, of course, is that I'm not in love with
allowing the user to upgrade the DB schema right out from under an
older MBE; I just can't see how this is expected to work in general.
[For instance---what if someday it was decided to use UTF8 and not
Latin1 in the DB?  I can't imagine an old MBE coping well with this
sort of transition.]

Potential gotcha, but not a big one:  In a single-machine FE/MBE
installation, we need to make sure that packagers start the MBE first,
so it can upgrade, and then the FE may start, so it doesn't ask a
useless question/block while the MBE is upgrading itself.  I doubt
most packagers auto-start the FE, though the user might have set it
to do so w/a script if this is an upgrade and not a fresh install.

No doubt I've missed yet another constraint here.  But what?

P.S.  Extra added bonus would be another DB setting:

AlwaysBackupDBOnUpgrade (yes, ask, no)
...with the obvious semantics.  That probably also requires a couple
of other settings like WhereToBackItUp and HowManyVersionsToKeep. :)
We could set those by asking the user if "yes" or "ask" is chosen.

[Do we repair/optimize the DB before allowing an upgrade to commence?
Should we?  Seems like a good idea---it might lessen the risk that a
crashed table will stop the upgrade in an unfortunate place, with
indeterminate results.]


More information about the mythtv-dev mailing list