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
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
