[mythtv] Renewing PostgreSQL support

BP lists at qucae.com
Tue Jun 22 02:43:22 UTC 2010


Michael T. Dean wrote:

> And, even if we were to completely document all the data requirements 
> and we were able to teach every user all the SQL they needed to safely 
> touch the database and we were actually able to get users to read all 
> this wonderful documentation, we still have a lot of external, 3rd-party 
> client applications that are directly hitting the database, corrupting 
> data, and making the fallout MythTV's problem.  So, we need to protect 
> the most important part of MythTV--the MythTV data--not from users, but 
> from clients that users choose to run that don't keep up with changes to 
> the MythTV database schema and data requirements.
> 

So because some users are using poorly written tools/clients you're 
going to lock down the other users who are responsibly accessing the 
data?  One of the great things about mythtv is that it gives users as 
much control and access as they desire.  It really seems that recent 
proposals are trying to lock down on a vision and reduce flexibility. 
It's been well understood for years this is a project that targets its 
developers and other technical people rather than trying to be 
universally appealing. I also don't see a significant volume of messages 
on -users or in trac resulting from corrupted data and I've been reading 
the lists daily for nearly 7 years.  If someone screws up their data, 
point them to a nightly backup and send them to the third party client 
to bitch and moan.

I personally edit the database a few times a month.  There are some 
things which can be done much faster directly through mysql than through 
the UI.  I occasionally get a firewire tuner stuck on an encrypted 
channel which requires setting the last watched channel to a good 
channel (mythtvsetup can also reset this, but it's slow and 
inconvenient).  The external database also makes it really easy to 
switch between a test/dev environment and a production environment (as 
well as merge data between them).  As mythvideo gets more and more 
automated, I imagine I'll be needing to edit the metadata more 
frequently.  The asinine algorithm that automatically determines if two 
files are multiple parts of the same video already makes me run a 
regular query to  reset all childid entries (it's great having an R 
rated movie automatically start when a G rated movie ends because one 
file contained a number).  The automatic metadata queries already have 
me thinking  I'll have a lot more stuff to clean up going forward.

Creating a robust protocol and encouraging third party tools/clients to 
adopt it seems like the prudent thing to do.  Forcing users to learn 
python and not exposing all the abilities of mysql doesn't seem like the 
right direction to me.

Ultimately those doing the work have the right to do as they wish.



More information about the mythtv-dev mailing list