[mythtv] Re:Mini patch: DVB Pids

[Edward Wildgoose]

> On Monday 25 August 2003 10:58 pm, Kenneth Aafloy wrote:
> > >On Monday 25 August 2003 08:58 pm, Kenneth Aafloy wrote:
> > > > Isaac Richards wrote:
> > > > > On Monday 25 August 2003 07:21 pm, Ramon Roca wrote:
> > > > > > In a summary, since I just though that wasn't 100% static, to
aviod
> > > > > > a need for a software upgrade in case that a change occurs, make
> > > > > > easier future customizations and, at all, all of this is just
data,
> > > > > > I just though that was the right place to be.
> > > > >
> > > > > The database scripts are going away in the near future, so I
really
> > > > > don't see much difference in changing some data structures in the
> > > > > source vs changing some sql inserts in the source.
> > > >
> > > > What about when we hit the point where release cycles are longer,
> > > > normal users take to it, from packages that is not updated often?
> > >
> > > They'll do the same thing as they would have to do now -- use CVS.
> >
> > Heh, this sounds like something, why don't we move the settings table
too?
>
> Um, what?

His point was that if we have to hard code all the settings for all the
satellites and upgrade the whole lot, ie no user customisation, then it's
not much more of a step to hard code all the settings into myth and just get
the user to recompile to change things...

Since we seem to be discussing this at more than reasonable length, then I
can only assume that one side or the other is missing some critical point,
because this isn't rocket science. (It may well be me, so please help me
out)

Let me try again (lets also try and slice this up into stuff that is ok, and
stuff that needs discussion still):

1) Table prefixes.  I'm a big buyer of these.  I would suggest a coding
standard for myth which is something like adding a prefix onto all tables to
seperate them so it is clear which module they relate too.  Stuff which is
used globally would not have a prefix though, eg the settings table.  There
is no need to do a mad rename now, but the smaller projects could certainly
do one for a next release, and new stuff should start properly right now.
All dvb stuff can have a DVB_ prefix and I'm happy to change the code to
make that happen.

2) We don't have to add all these tables to the DB if the user isn't using
them.  But in practice do we really gain anything by not doing this?  The
storage requirement is miniscule and who's going to know anyway? (answer
developers and users who want to tweak the stuff anyway, and at least it's
easier than having to recompile)

3) Some of the tables contain user customisation at setup time, these are:
channels_dvb, conditionalaccess, diseq and diseqcports - I hope that
everyone is happy with these going in? (obviously after renaming)

4) Stuff which is somewhat static: crypt, providers, languages, satellites.
Obviously they get pre-fixes to the name.  However, where else should we put
them?  They are foreign key relationships in the DB, and good DB design
tells us that we should have them in the DB and fix that relationship.  More
compelling though is the fact that the code is likely to want to join the
channels tables with the crypt and satellites table and get back a nice long
row of data to feed into the tuner.  If we hard code some of the info then
we are likely to find one of two things happening, either the developer will
be pulling stuff back from the DB and then cross referencing with internal
static structures (which need to be kept in sync across backends), which
generically is what a database is used for(!), or b) they are more likely to
just cheat and bloat the tuning tables with redundant columns, eg channel 6
needs these crypt params, and to point in this direction, etc.  (Nasty,
duplication, redundancy, etc)

5) I would always put all my data in one place anyway (static or not).  A
database is by definition a generic device for storing and retrieving data.
Our biggest issue at my workplace is when users start putting the "gold copy
data", ie the original source data into spreadsheets, text files, emails,
etc.  We always try and get everything into our central database and then it
becomes available everywhere, rather than needing every app to manually
patch together some data from a spreadsheet with some other data from a
database.  It's incredibly cool to be able to cross reference a number of
different data sources with a couple of lines of code and really works well.


Anyway, to avoid going way off topic, lets please all try and focus on just
the bits which are controversial without throwing out all the stuff which
isn't  (hopefully it's just number 4 above).

Isaac, perhaps it would help if you could tell us more about how/why the sql
scripts are disappearing?  It's hard to read minds, and perhaps whatever you
are doing there will give us some ideas as to how to better handle this
stuff here.

Also, I'm having trouble following your logic here:

> The database scripts are going away in the near future, so I really
> don't see much difference in changing some data structures in the
> source vs changing some sql inserts in the source.

I actually see a whacking great difference.  You seem to be assuming that
the only way that once can edit the database is to pull down your sources,
edit them, recompile and re-run them.  What most people do (certainly this
is what I do), is get out their favourite DB browser, eg myphpadmin, mysql,
etc, and just tweak the tables by running a couple of insert scripts (seems
pretty easy to me).  The point being that if a satellites crypt params
change I see very little reason why you would want to issue a new myth
release when we can simply publish a patch to the DB?

This is the point that Kenneth was trying to (bluntly) make.  Why even put
the "settings" table in a DB, we could just get the user to recompile the
code after changing their preferences in the compiled in data structure.
(There certainly are a few programs which follow this model.)

Anyway, I have worked now in a couple of organisations which *absolutely
EMPHASISE* keeping code and data COMPLETELY seperate.  It has worked very
well for us, and I would urge you to consider doing the same thing

Thanks for listening

Ed W