[mythtv-users] mythtv dropping mysql???

[Brian J. Murrell]

On Sun, 2014-10-19 at 08:25 +0800, James Linder wrote:
> 
> But not so embedded that mythweb can’t work. I’ve never used sqlite but it does seem to look like a good and an easy solution. Presumably two processes can access the DB file, one in read-only mode.

http://www.sqlite.org/lockingv3.html is probably what you are looking
for.

Having been lurking this thread I must also express concern over a
database which cannot even be peered into.

I have some periodic database query (i.e. reading-only to report)
processes, many that I run nightly for example that provide me with
information in an interrupt driven manner (i.e. e-mails of reports),
rather than forcing me to poll (i.e. firing up the FE or using MythWeb
to actively browse for the information I am looking for) using tedious,
time-consuming interfaces.

On a daily basis, each morning in my e-mail, (for example) I get a
report of:
      * all of the "Pilot" episodes found by the Pilots and Premieres
        power search that are not yet scheduled and active
      * the amount of space left on each of my storage groups -- which
        amounts to the amount of "Deleted", "LiveTV", etc. programs on
        each storage group

just to name a couple.  The first has obvious benefits.  The second
alerts me to the point in time where MythTV is going to start expiring
things that have not yet been deleted, to make room for new recordings.
It also advises me as to how I can re-balance from a storage group that
has few Deleted recordings to one that has lots.

The idea of not being able to do this in a very well known/understood
language like SQL is worrisome.

When the embedded DB and associated DB server API (I don't recall what
it was being called earlier on in this thread) comes along, I hope
bindings to several popular languages will be available.  Moreover, I
hope a "read-only" SQL "passthrough" will be available so that everyone
that has investment in reporting from the mythconverg DB in MySQL can
maintain their investment with little retooling.

Surely allowing read-only SQL passthrough would not have any downside
would it?

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20141018/535b9cd1/attachment.sig>