Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


mythtv at kosowsky

Jan 12, 2010, 6:06 PM

Post #1 of 8 (963 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles

Matt Beadon wrote at about 13:14:02 -0800 on Tuesday, January 12, 2010:
> >
> > BTW it works like a charm and now I can see my myth recordings on my
> > XP laptop -- woohooo....
> >
> > Here is an updated version of the code with some minor usability
> > enhancements:
> >
>
> Great timing (for me)! I just got my new laptop running last night and
> fired up myth FE only to realize that I'd have to spend ages getting the
> settings cloned from my existing FE before I'd be happy using it. :( Then I
> found this thread, thanks! Haven't run it yet but I will when I get home.
>
> I'm interested in the delete hostname function since I happen to have a few
> leftover invalid entries in my DB from changing my hostname without doing it
> the "mythtv way".
>
> I'm not very familiar with mysql but I'd like to make the following
> suggestions that I think would go really nicely with the current functions:
> 1) list all hostnames that have some configuration info in the DB. This
> will let people like me clean up after their mistakes more easily using your
> delete hostname command. :)
> 2) grant privileges to user [at] hostnam (or user@"192.168.1.%" or some other
> wildcard for home networks) to allow the new FE to connect to the DB since
> by default only mythtv [at] localhos is allowed. The syntax for this is shown
> on this wiki http://www.mythtv.org/wiki/MythFrontend
> 3) similar to delete hostname: revoke privileges to users/hostnames that
> were added by mistake. After way too long online I cobbled together the
> following commands for example:
> use mysql;
> select HOST, User from user; [to show my mistakes like adding
> username=oops]
> show grants for oops@"localhost"; [.check that the user doesn't have access
> to mysql for some app other than mythtv]
> delete from user where host = "localhost" and user = "oops"; [clean up
> entries]
>
> Hmm #3 seems to involve more human interaction and double checking than I'd
> really suggest for a script... perhaps that one's a bad idea? At least now
> I'll have those commands saved in this thread.
>
> I still think that #1 would be great and perhaps #2 could be added as a
> function within the copy hostname? That way the new hostname is completely
> ready to go after the copy.
>

First of all, I have had to learn on the fly how to do #2-3 to get my
setup working. However, I think that #2-3 are not really appropriate
for this script for 3 reasons:
1. This script acts on the 'mytchonverg' database (or optionally
whatever you name it) while adding/deleting users and
granting/revoking privileges act on the 'mysql' database
2. To use this script you only need the password (i.e. privileges) to
modify 'mythconverg' while to add/delete users and privileges you
need root privileges -- so it really belongs in another script
3. Changing users and privileges are simple one line mysql commands
that are unlikely to cause damage. Plus there are mysql GUI's that
make this even easier. On the other hand, the purpose of this
script was to automate changes that would be difficult and
error-prone to do manually.

I like the idea of your #1 and will see about adding it...
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mythtv at kosowsky

Jan 12, 2010, 10:39 PM

Post #2 of 8 (889 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles [In reply to]

Matt Beadon wrote at about 13:14:02 -0800 on Tuesday, January 12, 2010:
> >
> > BTW it works like a charm and now I can see my myth recordings on my
> > XP laptop -- woohooo....
> >
> > Here is an updated version of the code with some minor usability
> > enhancements:
> >
>
> Great timing (for me)! I just got my new laptop running last night and
> fired up myth FE only to realize that I'd have to spend ages getting the
> settings cloned from my existing FE before I'd be happy using it. :( Then I
> found this thread, thanks! Haven't run it yet but I will when I get home.
>
> I'm interested in the delete hostname function since I happen to have a few
> leftover invalid entries in my DB from changing my hostname without doing it
> the "mythtv way".
>
> I'm not very familiar with mysql but I'd like to make the following
> suggestions that I think would go really nicely with the current functions:
> 1) list all hostnames that have some configuration info in the DB. This
> will let people like me clean up after their mistakes more easily using your
> delete hostname command. :)

Here is an updated version adding your #1:
--------------------------------------------------------------------

# !/bin/bash
#mythfrontendprofiledup
# Version 0.2, January 2010
#Jeff Kosowsky (with MUCH help from Ronald Frazier)
#Script to automatically copy and/or delete mythfrontend profiles.
#
# Note the program operates on the following tables:
# settings, keybindings, jumppoints, displayprofiles, displayprofilegroups
##############################################################################
#Default values
MYTHDB=mythconverg
USER=mythtv
PASSWD= #Blank means it will query
#############################################################################
function usage () {
cat <<EOF

Copy (or delete) a frontend from the mythtv database

Usage: ${0##*/} [options] OLDHOSTNAME NEWHOSTNAME
Copy over frontend settings from OLDHOSTNAME to NEWHOSTNAME
(note existing entries for NEWHOSTNAME are deleted first)

${0##*/} -d|--deleteonly [options] HOSTNAME
Delete HOSTNAME frontend from database

${0##*/} -f|--frontends
Show all frontend hosts listed in database

${0##*/} -h|--help
Display this usage message

where options are:
--mythdb|-m MYTHDB Use MYTHDB database [default is to use 'mythconverg']
--nobackup|-n Don't backup database to MYTHDB.<date>.sql
before editing database [default is to backup]
--passwd|-p PASSWD Use password PASSWD [Default is to query for password]
--user|-u USER Use user USER [default is 'mythtv']

Note: program will not delete the last mythfrontend profile nor will it make
any changes to NEWHOSTNAME unless OLDHOSTNAME exists.
EOF
}

ALLHOSTS="((select hostname from settings)
union (select hostname from keybindings)
union (select hostname from jumppoints)
union (select hostname from displayprofilegroups)) as HOSTS"

function display_hostnames ()
{
mysql --skip-column-names -u $USER -p$PASSWD $MYTHDB < <(cat <<EOF
select * from $ALLHOSTS where hostname != "NULL";
EOF
)
}

############################################################################

SHORT_OPTIONS="d,f,h,m:,n,p:,u:"
LONG_OPTIONS="deleteonly,frontends,help,mythdb:,nobackup,passwd:,user:"
PARSED_OPTIONS=$(getopt -n "${0##*/}" -o $SHORT_OPTIONS -l $LONG_OPTIONS -- "$@")
OPTIONS_RET=$?
eval set -- "$PARSED_OPTIONS"

# Parsing error or no flags
if [ $OPTIONS_RET -ne 0 ] || [ $# -le 0 ]; then
usage
exit 1
fi

while [ $# -ge 1 ]; do
case $1 in
--deleteonly | -d) deleteonly=1 ;;
--frontends | -f) shift; SHOWFRONTENDS=1;;
--help | -h) usage; exit 0 ;;
--mythdb | -m) shift; MYTHDB="$1" ;;
--nobackup | -n) nobackup=1 ;;
--passwd | -p) shift; PASSWD="$1" ;;
--user | -u) shift; USER="$1" ;;

-- ) shift; break;;
* ) echo "ERROR: unknown flag $1"; usage; exit 1;;
esac
shift
done
OLDHOST=$1
NEWHOST=$2

if [ -n "$SHOWFRONTENDS" ] ; then
if [ $# -eq 0 ] ; then
display_hostnames
exit 0
else
usage
exit 1
fi
fi

if [ -n "$deleteonly" -a $# -ne 1 ] || [ -z "$deleteonly" -a $# -ne 2 ] ; then
usage
exit 1
fi
if [ "$OLDHOST" = "$NEWHOST" ] ; then
echo "Error: NEWHOSTNAME can't equal OLDHOSTNAME"
exit 2
fi

if [ -z "$nobackup" ] ; then
backup=$MYTHDB-`date "+%m%d%y.%H%M%S"`.sql
echo "** Backing up myth database to: $backup"
mysqldump --order-by-primary -u $USER -p$PASSWD $MYTHDB > $backup
fi

if [ -n "$deleteonly" ] ; then
NEWHOST=$OLDHOST
fi
#########################################################################
# Inject mysql queries
mysql --skip-column-names -u $USER -p$PASSWD $MYTHDB < <( sed "s/<OLDHOSTNAME>/$OLDHOST/g;s/<NEWHOSTNAME>/$NEWHOST/g" <<EOF
-- DELETE:
-- Calculate number of hosts left other than NEWHOSTNAME (the one changing)
set @numotherhosts := (select count(distinct hostname) from
displayprofilegroups where hostname != '<NEWHOSTNAME>');

-- Check if OLDHOSTNAME exists in any of the relevant tables
set @oldhostexists :=
(select count(*) from $ALLHOSTS where hostname = '<OLDHOSTNAME>');

-- Only do deletions and insertions if:
-- @doit = @numotherhosts * @oldhostexists > 0
set @doit := @oldhostexists * @numotherhosts;
select if(@oldhostexists > 0, if(@numotherhosts > 0,
"** Deleting any frontend settings for '<NEWHOSTNAME>'...",
"Error: No other hosts left. Aborting deletions..."),
"Error: '<OLDHOSTNAME>' doesn't exist. Aborting all database changes...");

-- First delete entries for <NEWHOSTNAME> from the following tables:
-- settings, keybindings, jumppoints
DELETE FROM settings WHERE hostname ='<NEWHOSTNAME>' AND @doit > 0;
DELETE FROM keybindings WHERE hostname ='<NEWHOSTNAME>' AND @doit > 0;
DELETE FROM jumppoints WHERE hostname ='<NEWHOSTNAME>' AND @doit > 0;

-- Second Delete any existing entries and profiles corresponding to
-- NEWHOSTNAME from displayprofiles and displayprofilegroups tables
-- NOTE: We assume that the profilegroupids are unique to each hostname
-- (and they will be if you use this script to copy frontend settings)
DELETE FROM displayprofiles WHERE profilegroupid IN (SELECT profilegroupid
FROM displayprofilegroups WHERE hostname = '<NEWHOSTNAME>') AND @doit > 0;
DELETE FROM displayprofilegroups WHERE hostname = '<NEWHOSTNAME>' AND @doit > 0;

-- Third, reset AUTO_INCREMENT values for the profile tables
-- Note you need the PREPARE/EXECUTE because you cannot assign a variable to
-- AUTO_INCREMENT directly
SET @lastgroupid := (select max(profilegroupid) FROM displayprofilegroups);
SET @s = CONCAT("ALTER TABLE displayprofilegroups AUTO_INCREMENT=", @lastgroupid+1);
PREPARE stmt FROM @s;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

SET @lastprofileid := (select max(profileid) FROM displayprofiles);
SET @s = CONCAT("ALTER TABLE displayprofiles AUTO_INCREMENT=", @lastprofileid+1);
PREPARE stmt FROM @s;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
EOF

[ -z "$deleteonly" ] && sed "s/<OLDHOSTNAME>/$OLDHOST/g;s/<NEWHOSTNAME>/$NEWHOST/g" <<EOF
-- COPY OLDHOSTNAME SETTINGS TO NEWHOSTNAME
select if(@doit,
"** Copying over frontend profile from '<OLDHOSTNAME>' to '<NEWHOSTNAME>'...",
"");

-- First copy over settings for tables: settings, keybindings, jumppoints
INSERT INTO settings(value, data, hostname) SELECT value, data,
'<NEWHOSTNAME>' FROM settings WHERE hostname = '<OLDHOSTNAME>' AND @doit > 0;

INSERT INTO keybindings(context, action, description, keylist,
hostname) SELECT context, action, description, keylist,
'<NEWHOSTNAME>' FROM keybindings WHERE hostname = '<OLDHOSTNAME>' AND @doit > 0;

INSERT INTO jumppoints(destination, description, keylist, hostname)
SELECT destination, description, keylist, '<NEWHOSTNAME>' FROM
jumppoints WHERE hostname = '<OLDHOSTNAME>' AND @doit > 0;

-- Second copy over settings for profiles.
-- Create temporary Tables GroupIDMap and ProfileIDMap to map profilegroup's
-- and profileid's from displayprofilegroup and displayprofiles tables
-- so as to avoid conflicts and minimize wasted key space
CREATE TEMPORARY TABLE GroupIDMap (oldid INT UNSIGNED , newid INT
UNSIGNED);
INSERT INTO GroupIDMap(oldid, newid) SELECT DISTINCT profilegroupid,
@lastgroupid := @lastgroupid+1 FROM displayprofilegroups WHERE
hostname='<OLDHOSTNAME>' AND @doit > 0;

CREATE TEMPORARY TABLE ProfileIDMap (oldid INT UNSIGNED, newid INT
UNSIGNED);
INSERT into ProfileIDMap(oldid) SELECT DISTINCT profileid FROM
displayprofiles WHERE profilegroupid IN (SELECT oldid FROM
GroupIDMap) AND @doit > 0;
UPDATE ProfileIDMap set newid=(@lastprofileid := @lastprofileid+1)
where @doit > 0;

-- Third, use the temporary tables to copy the profiles
INSERT INTO displayprofilegroups (name, hostname, profilegroupid)
SELECT name, '<NEWHOSTNAME>', newid FROM displayprofilegroups INNER
JOIN GroupIDMap ON profilegroupid=oldid where @doit > 0;

INSERT INTO displayprofiles(profilegroupid, profileid, value, data)
SELECT G.newid, P.newid, value, data
FROM displayprofiles INNER JOIN GroupIDMap G ON profilegroupid=G.oldid
INNER JOIN ProfileIDMap P ON profileid=P.oldid where @doit > 0;
EOF
)
###########################################################################
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mythtv at kosowsky

Jan 13, 2010, 3:16 PM

Post #3 of 8 (877 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles [In reply to]

Jeffrey J. Kosowsky wrote at about 01:39:53 -0500 on Wednesday, January 13, 201
> Here is an updated version adding your #1:
> --------------------------------------------------------------------
>
> # !/bin/bash
> #mythfrontendprofiledup
> # Version 0.2, January 2010
> #Jeff Kosowsky (with MUCH help from Ronald Frazier)
> #Script to automatically copy and/or delete mythfrontend profiles.
> #
> # Note the program operates on the following tables:
> # settings, keybindings, jumppoints, displayprofiles, displayprofilegroups
>
> # ############################################################################

Just to add some fuel to the fire...

I just realized another *good* use for this program.

Suppose you want to play with some frontend settings but don't want to
have to remember them all and undo them later. Also, you are only
playing with one of the frontends so you don't want to backup and
restore the entire database which could interfere with other database
changes (either from the scheduler or from other frontends).

Well you can use my program to *temporarily* save the frontend settings to a
dummy hostname and then restore later.

For example:
- Save settings to dummy profile "tempfrontend"
mythfrontendprofiledup myfrontend tempfrontend
- Play around with settings or make temporary changes
- Restore old frontend settings
mythfrontendprofiledup tempfrontend myfrontend
- Delete saved copy
mythfrontendprofiledup -d tempfrontend

Now internally, the restore won't be perfect since the profilegroupids
and profileid's will be increased but that shouldn't affect the user.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Jan 13, 2010, 3:34 PM

Post #4 of 8 (870 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles [In reply to]

On 01/13/2010 06:16 PM, Jeffrey J. Kosowsky wrote:
> Jeffrey J. Kosowsky wrote at about 01:39:53 -0500 on Wednesday, January 13, 201
> > Here is an updated version adding your #1:
> > --------------------------------------------------------------------
> >
> > # !/bin/bash
> > #mythfrontendprofiledup
> > # Version 0.2, January 2010
> > #Jeff Kosowsky (with MUCH help from Ronald Frazier)
> > #Script to automatically copy and/or delete mythfrontend profiles.
> > #
> > # Note the program operates on the following tables:
> > # settings, keybindings, jumppoints, displayprofiles, displayprofilegroups
> >
> > # ############################################################################
>
> Just to add some fuel to the fire...
>
> I just realized another *good* use for this program.
>
> Suppose you want to play with some frontend settings but don't want to
> have to remember them all and undo them later. Also, you are only
> playing with one of the frontends so you don't want to backup and
> restore the entire database which could interfere with other database
> changes (either from the scheduler or from other frontends).
>
> Well you can use my program to *temporarily* save the frontend settings to a
> dummy hostname and then restore later.
>
> For example:
> - Save settings to dummy profile "tempfrontend"
> mythfrontendprofiledup myfrontend tempfrontend
> - Play around with settings or make temporary changes
> - Restore old frontend settings
> mythfrontendprofiledup tempfrontend myfrontend
> - Delete saved copy
> mythfrontendprofiledup -d tempfrontend
>
> Now internally, the restore won't be perfect since the profilegroupids
> and profileid's will be increased but that shouldn't affect the user.

All of that's fine. I have no problems with the functionality.

My /ONLY/ complaint is that it's a bash hack that's a 3rd-party (not
part of MythTV, therefore, not maintained when MythTV is changed) script.

As I mentioned at the start of the script, I would prefer to see you
spend all of this time you're--pardon the bluntness, but--wasting on
this script on the /actual/ solution that will go into MythTV:

http://svn.mythtv.org/trac/ticket/6064

and, when it goes in, it will completely obsolete this script.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mythtv at kosowsky

Jan 13, 2010, 3:56 PM

Post #5 of 8 (873 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles [In reply to]

Michael T. Dean wrote at about 18:34:15 -0500 on Wednesday, January 13, 2010:
> On 01/13/2010 06:16 PM, Jeffrey J. Kosowsky wrote:
> > Jeffrey J. Kosowsky wrote at about 01:39:53 -0500 on Wednesday, January 13, 201
> > > Here is an updated version adding your #1:
> > > --------------------------------------------------------------------
> > >
> > > # !/bin/bash
> > > #mythfrontendprofiledup
> > > # Version 0.2, January 2010
> > > #Jeff Kosowsky (with MUCH help from Ronald Frazier)
> > > #Script to automatically copy and/or delete mythfrontend profiles.
> > > #
> > > # Note the program operates on the following tables:
> > > # settings, keybindings, jumppoints, displayprofiles, displayprofilegroups
> > >
> > > # ############################################################################
> >
> > Just to add some fuel to the fire...
> >
> > I just realized another *good* use for this program.
> >
> > Suppose you want to play with some frontend settings but don't want to
> > have to remember them all and undo them later. Also, you are only
> > playing with one of the frontends so you don't want to backup and
> > restore the entire database which could interfere with other database
> > changes (either from the scheduler or from other frontends).
> >
> > Well you can use my program to *temporarily* save the frontend settings to a
> > dummy hostname and then restore later.
> >
> > For example:
> > - Save settings to dummy profile "tempfrontend"
> > mythfrontendprofiledup myfrontend tempfrontend
> > - Play around with settings or make temporary changes
> > - Restore old frontend settings
> > mythfrontendprofiledup tempfrontend myfrontend
> > - Delete saved copy
> > mythfrontendprofiledup -d tempfrontend
> >
> > Now internally, the restore won't be perfect since the profilegroupids
> > and profileid's will be increased but that shouldn't affect the user.
>
> All of that's fine. I have no problems with the functionality.
>
> My /ONLY/ complaint is that it's a bash hack that's a 3rd-party (not
> part of MythTV, therefore, not maintained when MythTV is changed) script.

True -- I started this as a simple question and hack with hopefully a
simple answer and it has mushroomed...

> As I mentioned at the start of the script, I would prefer to see you
> spend all of this time you're--pardon the bluntness, but--wasting on
> this script on the /actual/ solution that will go into MythTV:
>
> http://svn.mythtv.org/trac/ticket/6064

OK - but I only saw this mentioned in post 19 of the thread, 3 days
after I posed the question and long after I had already started down
the other path.

Also 'wasted' is not only blunt (which is ok) but a matter of
perspective -- personally, I have *learned* a lot both about mythtv
and about sql so I don't regret the time spent even if the patch were
released into 'fixes' tomorrow. And long term such knowledge will make
me not only a better user but a better contributor...

Also, to be blunt in return, it is unclear to me when the patch will
be introduced into 'fixes' and it seems that while introduced 13
months ago, noting has been added in 3 months now and it is not
obvious when (if ever? lol) it will make it to stable release. So in
the meantime, my script may be useful to some which is why I have
posted it to the list.

Finally, if you want my help, please let me know what needs to be
done. Though my ability to help test may be limited since I don't
have a setup to compile my own binaries (I use atrpms fixes branch
primarily).

> and, when it goes in, it will completely obsolete this script.

That's great and of course a better long term approach for everybody!
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Jan 13, 2010, 4:13 PM

Post #6 of 8 (874 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles [In reply to]

On 01/13/2010 06:56 PM, Jeffrey J. Kosowsky wrote:
> Michael T. Dean wrote at about 18:34:15 -0500 on Wednesday, January 13, 2010:
> > On 01/13/2010 06:16 PM, Jeffrey J. Kosowsky wrote:
> > > Now internally, the restore won't be perfect since the profilegroupids
> > > and profileid's will be increased but that shouldn't affect the user.
> >
> > All of that's fine. I have no problems with the functionality.
> >
> > My /ONLY/ complaint is that it's a bash hack that's a 3rd-party (not
> > part of MythTV, therefore, not maintained when MythTV is changed) script.
>
> True -- I started this as a simple question and hack with hopefully a
> simple answer and it has mushroomed...
>
> > As I mentioned at the start of the script, I would prefer to see you
> > spend all of this time you're--pardon the bluntness, but--wasting on
> > this script on the /actual/ solution that will go into MythTV:
> >
> > http://svn.mythtv.org/trac/ticket/6064
>
> OK - but I only saw this mentioned in post 19 of the thread, 3 days
> after I posed the question and long after I had already started down
> the other path.
>
> Also 'wasted' is not only blunt (which is ok) but a matter of
> perspective -- personally, I have *learned* a lot both about mythtv
> and about sql so I don't regret the time spent even if the patch were
> released into 'fixes' tomorrow. And long term such knowledge will make
> me not only a better user but a better contributor...
>

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." :)

> Also, to be blunt in return, it is unclear to me when the patch will
> be introduced into 'fixes' and it seems that while introduced 13
> months ago, noting has been added in 3 months now and it is not
> obvious when (if ever? lol) it will make it to stable release. So in
> the meantime, my script may be useful to some which is why I have
> posted it to the list.
>
> Finally, if you want my help, please let me know what needs to be
> done. Though my ability to help test may be limited since I don't
> have a setup to compile my own binaries (I use atrpms fixes branch
> primarily).
>
> > and, when it goes in, it will completely obsolete this script.
>
> That's great and of course a better long term approach for everybody!

Right now, we're waiting on conversion of the UI portions of the patch
to mythui. We aren't adding any new UI code that does not use the new
UI libs, now.

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.

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.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mythtv at kosowsky

Jan 13, 2010, 6:31 PM

Post #7 of 8 (853 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles [In reply to]

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." :)

Agreed..

> 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
tables.

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.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mythtv at kosowsky

Jan 13, 2010, 6:40 PM

Post #8 of 8 (860 views)
Permalink
Re: UPDATED: Bash/MySQL script for copying and/or deleting mythfrontend profiles [In reply to]

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." :)
>
> Agreed..
>
> > 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
> tables.
>
> 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
multiple times).

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.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.