[mythtv-users] UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles
Jeffrey J. Kosowsky
mythtv at kosowsky.org
Thu Jan 14 02:40:40 UTC 2010
Jeffrey J. Kosowsky wrote at about 21:31:56 -0500 on Wednesday, January 13, 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
> complicated since
> - 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
> c++ code.
> > 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.
On the other hand, I admit that my code is a bit of a hack in that I
use some hairy bash and sql code so that I can call all the sql
queries in one batch (to avoid having to store or enter passwords
If enough people think this code is worth maintaining in either the
medium or longer term, I could recode it in perl that would give me a
lot more flexibility to use loops and control structures... to improve
the clarity, functionality, and extensibility of the code. In
particular this would allow me to define common subroutines...
But I don't want to get into competition with the mythtv developers --
if they want to use the code in the proposed patch.
More information about the mythtv-users