[mythtv] Schema updates

Isaac Richards ijr at case.edu
Sun Mar 4 18:43:21 UTC 2007


On Sunday 04 March 2007 12:02:24 am f-myth-users at media.mit.edu wrote:
>     > 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.)

So, your solution would be to only fix the problem for you, and leave people 
with other types of configurations out?  Adding additional manual actions for 
people who obviously want the simplest setup doesn't really make sense to me.

> 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.

The vast majority of users use packages and have single machine setups, and so 
don't tend to have this problem. =)

>     > 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.]

This has been discussed before, but a rough outline is:

- separate server app to handle the db access.  Owns the schema, not the 
fe/be.  
- autodiscoverable, with as minimal configuration as possible for initial 
setup/etc.
- add various canned queries to lessen impact of a direct mysql dependency on 
slim clients.  Slowly move at least some queries directly from the 
frontend/backend to use canned queries as well (ie, takes care of at least 
some backwards compatibility issues)

Basically, among other benefits, yes, it will completely make this issue go 
away.  Unless you 'accidently' stop your mythdbserver or whatever it's called 
and run a new version, I guess. =)

> 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.

Why would code be thrown away?  I don't see the need for that, unless we start 
removing functionality or something.

> 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?

Where exactly did I say that?  If something's implemented sanely, sure, it'll 
be accepted.  If it adds extra work for most people, though, then it wouldn't 
be something I'd consider sane.

> 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?

Uh, no.  I believe by this point, you've complained about this often and 
verbosely enough that you likely could have written a patch in less time than 
all the various emails you've written about it.  It's certainly wasted more 
developer time than reviewing and commenting (and possibly committing) a 
patch would have.

Write a patch.  It'll work for you, and I can promise that it'll be considered 
for inclusion, at the very least.

>     > 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.)

I think you're reading a different list than I am.

Isaac


More information about the mythtv-dev mailing list