[mythtv] WARNING - CVS drops DVB tables

Bruce Markey bjm at lvcm.com
Wed Jan 26 22:00:05 EST 2005


Isaac Richards wrote:
> On Wednesday 26 January 2005 07:09 pm, Nigel Pearson wrote:
> 
>> Running CVS frontend on a 0.16 backend seems to do this:
>>
>>DROP TABLE IF EXISTS dvb_channel
>>DROP TABLE IF EXISTS dvb_pids
>>DROP TABLE IF EXISTS dvb_sat
>>
>>after creating dtv_multiplex. Now, this would be fine
>>if the machine was CVS-only, but if you happen to test
>>against a working DVB backend, you will break it.
> 
> 
> That's by design.  Backwards compatability is for wimps. =)  Can't guarantee 

Wah, wah! Isaac is pickin' on me.

> it, and if you were using other new features of CVS (new recording types, 
> etc), 0.16 would also break.

If a rule with a new type was added it may not be handled gracefully,
that's true. If something needs to be renamed or changed in a way
that breaks things then, oh well. However, this removes useful
data for no advantage.

I have several test DBs and I do go back and test issues with
recent versions. This is usually not a problem because almost
all changes are adding a new table or columns to existing tables.
Having new fields that an old version doesn't refer to is a NOOP.
ALTERs to make a larger varchar or NOT NULL or change timestamp to
datetime generally don't break anything either. In fact, the last
time backwards compatibility came up, I was able to run 0.9 by
simply replacing two columns that had been renamed.

Unless some one has a reason why the current code won't work unless
these tables are removed (rhetorical, I guess ;-) I'd be happy to
remove these DROP TABLEs for now.

--  bjm

 


More information about the mythtv-dev mailing list