[mythtv] Scheduler needs table keys?

[Michael T. Dean]

On 03/03/2007 02:31 AM, Chris Pinkham wrote:
>> I still wish this was a supported part of Myth, though. :)
>> These rogue updates (e.g,. new frontend smashes the backend)
>> generate a fair number of "d'oh!" messages to the list and no
>> doubt quite a bit of headache for those who trip over them.
>>     
> But then we'd have just as many people asking why their backend won't
> startup because they need to go modify some startup script to force it
> to allow automatically upgrading the schema, then they have to remember
> to restart the backend after removing the command line argument and
> restart again or else the next DB upgrade would be applied automatically.
>
> I can see an argument for making it so that only the master backend
> or mythtv-setup would automatically upgrade the DB while slave backends
> and the frontend would exit and print an error message about the DB being
> the wrong/old schema version, but I'm not sure if that idea would be
> accepted.

If it's mythtv-setup, only, we'd have a long road to walk teaching 
people to run mythtv-setup every time they upgrade.  And then we'd get 
the pundits on the list encouraging others to be lazy by saying, "Well, 
since you're upgrading from r19872 to r19893, you don't need to run 
mythtv-setup first, but if you were upgrading to r19894, you'd need 
to..."  IMHO, when those messages start appearing--and unsuspecting 
users take them as upgrading instructions or, worse, official 
recommendations--it would be far worse than the current situation (i.e 
"Welcome to the ranks of SVN trunk users.  Please ensure you sign up for 
the mythtv-dev and mythtv-commits lists and read all the messages, since 
SVN trunk users are expected to keep up.").

If the master backend is allowed (or also allowed, along with 
mythtv-setup) to upgrade the schema, the change would have no effect on 
users of combined frontend/backends who "test out" SVN trunk or a 
"one-time" build of -fixes and then try to go back to using their 
packager-provided -fixes build.  Generally, I think the only people it 
would purport to "help" are the people who should know better (i.e. 
those running multiple frontends/backends are more likely to know a 
thing or two about Myth...).  They should at least know that upgrading 
is a one-way road; should probably know that all frontends/backends must 
be running the "same version" of MythTV; and possibly may know how to 
create a test/dev system that doesn't hit the same database...

Personally, though, I don't care either way--it won't affect me because 
I do and will understand the issues and the proper procedure for 
upgrading (not to mention the three pieces of info I discussed above).

Mike