[mythtv-users] UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles
Jeffrey J. Kosowsky
mythtv at kosowsky.org
Thu Jan 14 02:31:56 UTC 2010
Michael T. Dean wrote at about 19:13:24 -0500 on Wednesday, January 13, 2010:
> OK. Perhaps I should have said, "Now that you've gotten some practice,
> feel free to contribute any missing parts to the patches on #6064." :)
> You may have added functionality to your script that doesn't exist in
> the patch. If so, that functionality should be added to the patch,
> too. So, if you're not a UI guy, you could always look at the DB code
> in there and update it if it's missing anything.
Unfortunately I'm neither a UI guy nor am I a C++ programmer but I
learned enough 'C' back in the day to at least understand the code.
That being said, the code seems rather limited compared to my hacked
script. If I am reading it correctly, it only really
adds/deletes/changes the hostname column entries in the 'keybindings'
and 'settings' table.
First, adding the missing 'jumptables' would be trivial since the
replacement approach follows the same structure as for the other
Second, the code doesn't seem to touch the interjoined
'displayprofiles' and 'displayprofilegroups' tables which are more
- They are interconnected by the common profileid key
- The use of numerical keys means you want to be clever about
numbering so that you don't unduly waste key space.
The way that Ronald Frazier helped me code uses temporary tables to
create the mappings that address both issues. The approach does not
try to fill every hole (as I believe even mythtv doesn't do when
creating new entries) but rather packs new entries tightly above the
AUTO_INCREMENT value of each table.
Also, when deleting, the AUTOINCREMENT value is adjusted (which I'm
not sure that even mythtv does when it deletes entries from other tables).
Additionally, hostname can (and does) appear in tables used by other
plugins (such as mythweather). Since I don't use those tables, I
haven't (yet) coded that in. But one can't just blindly change
'hostname' in all tables since the key is used for both backend and
frontend tables -- personally, I would suggest that the schema be
changed to distinguish between frontend and backend usage of
hostname. Also, there is no guarantee that plugins won't also use
interconnected tables like with displayprofiles/displayprofilegroups.
Also, my code backs up the database -- just-in-case -- which might be
a nice feature to add to this code.
Finally, the proposed code seems to be more about saving/restoring
settings. It's not clear to me that cloning or deleting frontend
profiles is/will be implemented. Nor the ability to list the frontends
in the database -- all of which I have implemented directly or can be
easily done with my script.
To be honest (and perhaps at total odds with your philosophy), I would
be *more* comfortable using my code now than this code. My code is
admittedly a hack but at least the sql queries are clear and concise
vs. this c++ code scattered over 100's of lines that really only does
the easy part of my script -- the simple "DELETE FROM" and "INSERT INTO"
queries "WHERE hostname = XXXXX" which can be done in about 6 lines.
Maybe I'm going out on a limb here but I think that doing this within
mythfrontend itself will always be a kludge unless/until the following
philosophical/architectual changes are made:
1. Usage of hostname as a column name is clearly distinguished between
frontend-specific vs backend-specific usage so that the code can be
generalized to act on all frontend-specific variables that appear
in simple tables analogous to settings, keybindings, jumptables.
(more generally, it has always frustrated/confused me that the
settings in mythfontend don't distinguish between ones that are
specific to individual frontends vs. ones that make sense (or even
can be) customized across frontends.
2. A procedure is set out so that plug-ins that use interconnected
tables (analogous to displayprofiles/displayprofilegroups) are
required to provide a hook and SQL code to copy/save/delete their
entries for new/saved/deleted hostnames.
Otherwise, I think that the integrated code approach will only be
hiding the very subtleties that you worry about in my approach -- but
in a way that is much more insidious since the code will be buried and
forgotten and not well-known to developers who add new tables either
in the core or in plugins. And when new plugins are added, it is a lot
easier to modify and test a bash script than to change deeply embedded
> And, if you're just feeling like helping out, you could always make the
> code in the patch more compliant with the coding guidelines
> (specifically in the programs.patch and mythdb.patch portions). The
> main part that will need fixing is changing the SQL to capitalize the
> SQL keywords--primarily in mythdb.patch, it seems. However, if the UI
> portion were fixed, I could do the style changes and get the patch into
> trunk very quickly--and before 0.23 is released.
I'm not sure the code is ready for that -- I think some of the more
general issues listed above need to be addressed.
More information about the mythtv-users