[mythtv] Renewing PostgreSQL support

[Lennart Sorensen]

On Mon, Jun 21, 2010 at 08:36:33PM -0400, Michael T. Dean wrote:
> Well, that's where you come in.  Any data you need made available needs  
> to be made available through some non-direct-access protocol--so that  
> the backend can prevent any data integrity issues.  So, just code up  
> patches to make available whatever data you need.  (That said, the only  
> real difference you're likely to notice is that the mysql command-line  
> app will no longer be used to access the data.  You'll still have full  
> access to all your data--you'll just access it in a way that doesn't  
> involve SQL.)
>
> I recognize that many MythTV users are SQL experts, and--therefore--they  
> can modify data in the database directly without corrupting that data  
> (regardless of the fact that the data integrity rules are not expressed  
> in the database and all data checks are done in application code in  
> MythTV).  That said, some users aren't "SQL experts" (and some people  
> who understand databases also understand that knowing SQL doesn't mean  
> you understand the data requirements and constraints).
>
> 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.

If that is in fact the goal, then you don't have to use an embedded mysql
to do it.  Just add the client database access to the mythtv protocol so
that clients have the option to use that.  Given the choice, I would think
most clients would rather not have to deal with the schema stuff at all.
The database could then be configured to only allow access from the
backend, but would still be possible to access as any other mysql database
for those that want to.  Whether to use an external or internal mysql
could be a config option.  Should be pretty simple the allow that.
In either case the access to the data would be through the mythtv
protocol.

> No, the DB is just wherever you run the MythTV data server program.   
> Initially (at least) that program will be the master mythbackend (i.e.  
> the only program/process that does the MythTV scheduling--and,  
> therefore, needs to run the BUSQ).  Likely the mythbackend program will  
> be a mythbackend that doesn't require capture cards (as the capture  
> portion of mythbackend will likely be split out from the  
> scheduler/housekeeper portion).  It's actually adding far more  
> capability than we currently have in terms of what can run where.
>
> As was already mentioned on the -users list, a handful of lines of  
> Python code will allow you to set up your own means of streaming the  
> files from the backend so they can be played on the frontend using any  
> external player (and the mythfs.py FUSE file system (  
> http://www.mythtv.org/wiki/Mythfs.py ) may actually provide support for  
> it, already, but I don't know the current status of it and MythVideo).
>
> Besides, what's really been said is that MythTV is moving away from the  
> requirement for having local files on all systems, which will impact  
> usability of external players.  It is not yet decided that external  
> player support will be removed (only that it will change because it's a  
> mess now and requires significant effort to maintain--since we basically  
> have to write and maintain the code for each new MythVideo feature added  
> two times:  once for Internal and once for external players).

If the internal player works, I certainly won't miss the external one.

-- 
Len Sorensen