[mythtv-users] mythtv dropping mysql???

[Rich Freeman]

On Wed, Oct 22, 2014 at 12:46 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 10/22/2014 11:09 AM, jedi wrote:
>>
>>      As far as the "appliance" thing goes, one of my own examples of "db
>> tinkering"
>> is a script that clones settings from one machine to another. This
>> simplifies the
>> task of setting up a new frontend considerably. All of the media storage
>> definitions
>> get cloned as well as a basic set of UI related settings. Since I use
>> roughly
>> standardized hardware for the frontends (ION), I also clone the decoder
>> profiles.
>
>
> This is not an example of something that requires direct DB access using
> non-MythTV tools.  This is an example of something that MythTV should allow
> all users to do easily from within the UI.  This is an example of something
> that hasn't been done because it's easy enough for devs or power users ***
> to do without creating a proper UI.  This is an example of a feature MythTV
> is lacking *because* the mysql-direct-database-access tools are a crutch
> we've been leaning on.

Sure, but there are lots of other use cases as well.

How about this one, run hourly from crontab:
UPDATE \`recorded\`  SET \`autoexpire\` = '1',
 \`preserve\` = '0' WHERE \`seriesid\` IN ('<bunch of ids>') ;

Do you REALLY want to create a UI for that?  Maybe have setting in the
recording rules that controls not only # of episodes to save and
autoexpire but also whether those flags can be toggled per-recording,
with role-based access control to who can edit the recording rule?  I
don't want to dump that on the devs.

Or (also run hourly):
UPDATE \`recorded\`  SET \`autoexpire\` = '0',
 \`preserve\` = '1' WHERE \`autoexpire\` = \`preserve\` ;

That saves me having to toggle two flags at a time in the UI.  If we
want to have another button that switches them together I'm fine with
that.

Another one I was running in the past was dealing with failed jobs,
but that is something that should be part of the application.

Channel manipulation is another case where I tend to use SQL.

I don't expect the developers to cater to every one of my little
needs.  That's just one of the benefits of having the data in a
database - they don't have to.  I do realize that some of this might
be doable via scripting, but unless the script just runs raw SQL on
the database you're not going to get the same performance out of it
and it is another "language" to learn.  If it does run raw SQL on the
database, then there is no way to control it and you get all the
downsides of allowing outside database access today.

For me though it is as much about just having access to the data and
knowing it is someplace I can get to and repair if there is a problem.
It is as much a control thing as anything else.  I realize that if I
break it I get to keep the pieces.

--
Rich