[mythtv-users] Converting scripts to not use the database directly
Michael T. Dean
mtdean at thirdcontact.com
Tue Nov 4 14:53:27 UTC 2014
On 11/04/2014 09:19 AM, Simon Hobson wrote:
> Michael T. Dean wrote:
>
>>> My observation was that we are taking a step back from being able to use a tool where all the looping is nicely handled for us. Instead, everyone who writes a script to operate with the API would, it appears, have to re-invent the wheel every time.
>> So it's that much harder to do:
>>
>> chanids = [1031, 1081, 1161, 1281, 1282, 1283, 1384]
>> for channel in Channel.GetChannelList(chanids)
>> channel.SetVisible(false)
>>
>> than
>>
>> UPDATE channel SET visible = 0 WHERE chanid in (1031, 1081, 1161, 1281, 1282, 1283, 1384);
> Just the same way that pretty well everything that can be done with AWK can also be done in shell - it's just that AWK is often the superior tool for the job. The parallel being that AWK is great for "looping over stuff" and automatically handles the looping in the background - instead of writing the loops in shell as can also be done.
>
> In any case, are you over simplifying the update to make it look "not as bad". Does the API have a fully flexible selection ability ? Ie, is "get a list of channels where<some arbitrary criteria>" doable directly with one call, or do we need to get a list of channels, iterate through them to select the ones to work on, and ONLY THEN do the simple bit you've written ?
>
> BTW - is doing an update really just "channel.SetVisible(false)" or is there more to it than that ?
That is the plan--simple to select with some arbitrary combination of
criteria and simple method calls to change one or more values of the
object. Much of it is already available, though it will become even
easier (for example, as more of the Services API becomes
available/useful and as the Python bindings start wrapping the services
API to make an easy-to-use API).
>>> I understand the desire to remove direct access ot the DB, but to remove a "good" tool (from the user's perspective) and replace it with what appears at the moment to be very inferior does seem a step backwards. IMO to be a "good" replacement the API needs to support set operations, arbitrary joins, arbitrary selections, and relative updates - which makes it sound rather like SQL ! It looks very much like at least 1 or 2 of those are missing.
>> You make an interesting point. I'll work on removing some of the inferior tools we have right away.
>>
>> In Watch Recordings, we currently have MENU|Playlist Options|Storage Options|Change Recording Group, which simply changes the recgroup. I don't know why someone put that in there when it's so easy to just:
>>
>> UPDATE recorded SET recgroup = 'Cancelled' WHERE chanid = '1071' AND starttime = '20141103200000';
> Well if you insist on making your self look stupid and silly, then make ridiculous comparisons like that.
>
> Clearly, the examples you give are "designed for the job". Since there is no "designed for the job" function that will automagically (in my example) setup the channels as I like them, then it needs to be done via an alternative method.
No, the right solution is to have designed for the job functionality to
do whatever you need more easily than can be done with even SQL.
> Applying reductio ad absurdum then hardly anything in Myth makes sense. If you persist in deliberately trying to make out that I have a different position to what I express, then you could argue that the whole scheduler is redundant as the user could do that themselves. The playback system is redundant as the user could just use (eg) VLC to playback a file. The user could manually delete files as the disk fills up. Etc, etc, etc.
>
> Put another way, what goes into Myth are all the functions that "most people need".
Yes, and if all these "SQL is the answer" threads have shown anything,
it's that "most people" actually /do/ need a lot more functionality than
MythTV offers in the UI. We need to add in generic data selection and
manipulation functionality such that--since we've been talking about
editing channel lists, I'll stick with that example--in the mythtv-setup
and backend web server channel editor, the user can select a bunch of
channels by specifying arbitrary criteria and/or by manual selection and
then apply changes to all of them (i.e. set them all as not visible or
disable EIT on all of them or increase channel number by
1/5/10/25/100/1000 or do whatever). And we need to do similarly for
recordings--select a bunch using arbitrary criteria and/or manual
selection, and then apply any user-editable data change to them all--and
anything else that users may need to edit...
> What doesn't go in is special functions that only a few people need. You seem to be arguing that because I point out the proposed changes make those special functions less easy to do, that is somehow equivalent to arguing that the common functions should be removed.
such that nearly everything almost every user needs to do can be done
via the user interface even more easily than it can be done with SQL, so
that when they need to do something that's unique/broken/wrong (where
I'll guess most all of the time it will fall into the latter 2
categories since people's requirements aren't nearly as unique as they
presume) they can either write or find a script (in the Scripts category
of the wiki or whatever) that allows them to do what they want. And
even if it is "harder" to use the Python bindings than SQL, it will be
such an uncommon occurrence (and/or it's just a matter of writing a
script once and using it forever), that it won't matter. In other
words, the goal is for scripting (in SQL or Python or whatever) to be
the exception and not--as it seems to be today (at least to some
users)--the rule.
So I really do intend to remove MENU|Playlist Options|Storage
Options|Change Recording Group and MENU|Storage Options|Change Recording
Group (and all similar functionality, including those I mentioned in my
previous reply) from mythfrontend and instead have functionality which
allows changing /any/ user-editable data easily for a single recording
or multiple at once. You may fear the "user-editable" qualifier in
there, but shouldn't because "user-editable" includes everything except
MythTV-internal values that can't be changed without breaking things
(like database IDs). If the internal-only data needs changing, that
means there's a serious bug in MythTV and the proper fix is to fix the
bug, not allow user editing of the internal-only values via the UI.
MythTV has a lot of user-editable data, and much of it users don't even
realize they can edit (such as recording title/subtitle/description),
often because they can't find the option in the UI. Having a single
place to go to edit whatever data makes it easy to edit anything. And,
for those who are worried that it's going to take more remote button
presses to toggle the watched flag or whatever since you'll have to
navigate around the data you're not wanting to change, you should be
able to do it as easily or more easily than you can now because I see
these screens as getting customizable menus, like the customizable OSD
menus that Jim Stichnoth added.
Mike
More information about the mythtv-users
mailing list