[mythtv] Renewing PostgreSQL support

[Michael T. Dean]

On 06/21/2010 10:43 PM, BP wrote:
> 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?

No, we're doing this because it makes things exponentially easier for 
developers.  The rest is all additional benefits.

>   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.

So, basically the problem here is not that SQL is easier--but that you 
haven't submitted patches to make all this easier than even using SQL.

> 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.

Again, people, you will still have the same access you have now.  It 
will just be using something other than SQL.

Besides, if you're a true power user, you can make SQL work with it.

Mike