[mythtv] Schema updates

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sun Mar 4 05:02:24 UTC 2007


    > Date: Sat, 3 Mar 2007 22:38:50 -0500
    > From: Isaac Richards <ijr at case.edu>

    > > That's part of why I don't understand the reluctance to making DB
    > > schema upgrades NOT happen AUTOMATICALLY from a FRONTEND.

    > There are users that don't use the tv recording functionality, and thus don't 
    > ever have the backend running, or ever run mythtv-setup.  That's reason 
    > enough for me to keep things as they are for now.

Isn't this a tiny percentage of Myth users?  Couldn't they set the
"dangerous" flag?  (Assuming we therefore -do- let frontends update;
another idea would be "this is a frontend-ONLY installation", which
is semantically cleaner and allows updates 'cause we know there's no
MBE.  Of course, multiple frontends get to fight it out among themselves.)

Otherwise, it seems we're allowing the vast majority of users to screw
themselves with simple mistakes to avoid asking a tiny minority to set
a flag just once for their unusual usage pattern and forget it forever
after.

    > It all becomes a non-issue if we move to an embedded db, too - the database 
    > (server/backend/whatever) itself will be the only thing upgrading the schema, 
    > then.

What about the frontend-only users above?  Are they talking to the
embedded DB and hence running a backend -anyway- in the new regime?
[I thought the embedded DB was architecturally identical to sucking
MySQL into the backend.  Apparently that's not the case if frontend-
only users currently don't talk to a backend at all, but will have to
with the EDB.  And I still don't understand how it prevents, e.g., a
-slave- backend from updating an MBE, or a frontend from doing so,
etc etc.  It seems that EDB is completely orthogonal to the whole
discussion, but I obviously don't know what you have in mind here.
Unless you're saying, "Once we go to EDB, FE's and SBE's will no
longer -need- to update the MBE because we'll always make sure the MBE
can speak in a backwards-compatible manner to them", which is a pretty
big change in paradigm and, again, doesn't seem necessarily related to
whether the database is MySQL or EDB.]

And it seems like it'd be a tiny amount of work now to protect
people, even if at some indeterminate time in the future (a year?
more?) we go to an embedded DB.  No doubt there'll be plenty of other
code thrown away at that point, anyway.

In any event, it sounds like you're saying, "No patch to implement any
functionality to prevent users from screwing themselves (or being
screwed by a rogue frontend) due to a DB update will be accepted."

Is this true?

If so, those other people who said, "Write up a patch and submit it
and it'll get looked at" are basically saying, "Go waste your time
because there's no chance it'll be committed."  That's part of why
I was trying to figure out whether it was worth -anybody's- time to
even -try- to address this issue.  Sounds like you'd step on any such
attempt.  True?

    > Really, though - the unapplied patch in question doesn't really do anything 
    > aside from remove some fairly low-overhead extraneous tests.  The valid 
    > portions of the guy's other patch (the freebsd stuff) got applied rather 
    > quickly.  The cosmetic one will get applied when someone has enough free 
    > time.  I believe that's rather reasonable.

I guess I managed to miss a commit message.  I sure didn't miss him
getting yelled at and threatened, though.  (I agree wrt assigning
cosmetic patches low priority, but I wonder if he'll ever bother to
submit anything else.  Guess we'll see.)


More information about the mythtv-dev mailing list