[mythtv-users] mythtv dropping mysql???

[Simon Hobson]

Michael T. Dean <mtdean at thirdcontact.com> wrote:

> It forces everyone--developers of MythTV /and/ everyone else--to access the data correctly, via requests to a data server, which can enforce data integrity constraints, rather than using direct database access because embedded MySQL does not support multi-client/network access.  This means that people will be forced to finally do things properly--instead of just hacking some SQL script to fix up their channels or running some quick SQL to modify some stuff in their database, someone will have to write the code to allow /anyone/ to fix up their channels easily or modify whatever stuff needs modifying in the database.
> 
> IMHO, the biggest problem with providing easy access to the underlying, internal-use data is that it provides a means by which people can selfishly solve problems for themselves rather than helping to solve the problem for everyone.

See that is exactly what bothers me.
I can do SQL, I can do shell scripts, I don't do C, Perl, ...

I read that as "you won't be able to fix things without learning ${approved language}". One of the things that really, really irritates me about our DVB-T (Freeview in the UK) is the "random" LCNs and regular retunes AND the absolutely s**t user interfaces on most gear for renumbering them. What this means is that if I want logical channel numbers on my kit then it can take several hours every time someone decides to shuffle some channels around.
Vs a few minutes on my MythTV system with a shell script that grabs the login credentials and runs a SQL script. It takes longer to rescan and look to see what the changes are (and update the script) than it does to actually fix the channel table.

Now you are suggesting that this will be possible **IFF** someone writes new code to expose that data. That's a big IFF.

That's my use case for direct data access.

PS - And it's not "selfish" to do that, my script is there on the Wiki for anyone to use (and adapt to their own use requirements).


As to the "lots of packages run embedded DBs, well are we into "everyone else does it so that makes it OK" territory ?


On 16 Oct 2014, at 22:27, Thomas Mashos <thomas at mashos.com> wrote:

> While that is true, it's pretty bad form to automatically tune a DB
> for MythTV if MythTV isn't the only thing using it.

I would agree.
But just how is ANY system going to sensibly tune itself unless it also knows what other packages are running on that system and what their requirements are ? You can't simply look at the available RAM and apply a "we'll use ${constant} % of it for the DB".

I'd suggest that tuning should be a user controlled thing - have the ability to tune the DB, but the user must initiate it and/or have the ability to override it. As I said, it's hard enough to come up with a *reliable* algorithm just to meet the different use cases for Myth - add in all the permutations of other packages and it becomes (IMO) impossible.
Also, having separate DBs (if you do have more than Myth running on the system) loses the ability to apply diversity.



It does sound like one of two things will happen :
1) There will be very very restricted access to the data - which in effect breaks things for quite a few people
2) There is full access, which by the sound of it means the devs having to write a whole query language shell to make the sanitised interface accessible. Doesn't sound probable or a good use of dev resources.