[mythtv] Renewing PostgreSQL support

[James Courtier-Dutton]

On 22 June 2010 01:36, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> On 06/21/2010 08:05 PM, Tom Dexter wrote:
>>
>> On Mon, Jun 21, 2010 at 2:10 PM, Michael T. Dean wrote:
>>
>>>
>>> On 06/21/2010 02:04 PM, Richard Morton wrote:
>>>
>>>>
>>>> I would expect that mSQL or SQLlite is sufficient for Myth; epecially
>>>> if the clients could be re-engineered to proxy requests to the db via
>>>> the backends.
>>>>
>>>
>>> The (Big Ugly) Scheduler Query is too much for SQLite.  We've done tests
>>> before and it just couldn't hack it.  It may be possible to make it work,
>>> but we have enough MySQLisms in the code that it's a lot easier just to
>>> go
>>> to an embedded MySQL--and doing so accomplishes some of our long-term
>>> goals.
>>>  Specifically, it would prevent anyone other than the master backend from
>>> accessing the database (since embedded mysql is not a client/server
>>> architecture and allows only single-process access to the DB)--meaning
>>> all
>>> clients would have access to all data via the protocol and the master
>>> backend would be able to ensure data integrity without worrying about
>>> clients breaking the data.
>>>
>>> I hope to start work on embedding MySQL after 0.24 is released.
>>>
>>
>> Wow...as someone who understands MySQL well and *really* likes having
>> access to the database, I have to tell you I really don't like that
>> one at all.  As a matter of fact, having access to that data is in
>> fact one of the (many) things I prefer about MythTV to proprietary
>> DVRs.
>>
>
> 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 agree. I would prefer the mythfrontend to not need any SQL.
It would protect the integrity of the database better.
mythtv-backend could then provide another better interface to the
mythfrontend. I.e. reduce the amount of data transfered across the
network when the frontend views the program guide.
So, the frontend could request: Give me the program guide from time X
to time Y, covering channel N and 3 above and 3 below.

I would also like the SQL bits of the mythtv-backend to be modularised
so that the Program guide is separated from the media streaming
functions.
I.e the parts of mythtv-backend that gather the stream form the source
and stores it on the hard disk to not have any SQL commands in it at
all.
Currently, any connectivity problems to SQL can cause recordings to fail.