[mythtv] Patch for generic SQL query

David Shay david at shay.net
Wed Apr 27 22:28:11 UTC 2005


----- Original Message ----- 
From: "Kevin Kuphal" <kuphal at dls.net>

> David Shay wrote:

<snip>

> I think for me, while it is a hole that should be considered, it is also
> about a good design.
>
> Lots and lots of commands make more sense to me from a protocol
> standpoint than a single command to inject SQL.  By having those
> commands as part of the protocol, mythfrontend and mythweb can also be
> modified to use them, providing a completely standard and repeatable
> method of accessing those structures in the database.  If a bug is found
> in those methods, changing it in the backend protocol handler fixes it
> for all frontends whereas, allowing each of them to create their own
> SQL, results in situations like with MythWeb where new features are
> added to the mythfrontend using SQL and someone has to recreate the
> wheel for MythWeb to achieve the same functionality.
>
> While adding individual commands maybe tedious, I think the advantages
> for all the mythtv clients are worthwhile.  The mvmpc and mythroku teams
> will not have to both create the same code to access our structures and
> then maintain them as they change.  Instead, the coding is inside the
> backend where it is maintained once for all projects and simply utilized
> by the client, making the client even thinner and simpler.

I really can't disagree at all from a design perspective.  When this came up
a few months ago, a few of us proposed adding several new commands to the
protocol to get at data that was only available through SQL, i.e. the
commercial cutlist.  At the time, Isaac and others didn't want to add many
new commands just to avoid adding a mysql client to other frontends.  This
was before multiple databases were supported, though.

When I chatted with Isaac on IRC last night, he said that the generic patch
would be accepted, as would specific other ones for specific pieces of
information.  We also agreed to start with the generic one first and then go
to specific ones.  I don't have a problem with making the specific
additions, either, but didn't want to add a ton of them for data that could
be retrieved from simple, relatively static tables.  Doesn't really matter
to me -- I'm more than happy to provide the specific patches as well, but I
do see some value in a hybrid approach: provide a specific protocol command
for high-use cases or where the database structure might be less stable, and
still provde the generic command for other cases.  That would tend to
stabilize the protocol over time, as well, so that it wouldn't be constantly
bumped for minor data queries.

Isaac, direction?




More information about the mythtv-dev mailing list