From: Jim F. <fl...@at...> - 2003-06-23 14:26:19
|
If it does not complicate matters a lot you may want to make it so PostgreSQL could also be used. ----- Original Message ----- From: Denis Cheong To: mis...@li... Sent: Monday, June 23, 2003 9:05 AM Subject: [misterhouse-users] Misterhouse MySQL Library I need to create a Misterhouse MySQL library that creates a persistent connection to a MySQL database that I plan on using for a lot of Misterhouse configuration that would be very messy to implement in control files. Such things are the mappings of TV channel names to TV channels, IR commands & macros, HTTP bookmarks, iButtons, and all sorts of other things that are possible to do dynamically so as not to require reloads of Misterhouse / modifications to source code each time they change. Even things like usernames and passwords are a great candidate to be stored in MySQL in md5 encoded fields (or the like). The routines to execute SQL queries need to be available to both "code" modules and to perl scripts resident in the "web" directories with a minimum of additional code - i.e. all that should be required is a single assignment statement to fetch the result of a SQL query in the "misterhouse" database into a hash, in the way that PHP does it with mysql_query(). I have implemented such an interface before in an old verison of misterhouse, but doing it back then I used an extra global added to the master mh perl script ($mysql_db in the main use_vars qw() line 6 of mh, initialised during startup). This time I'd like to do it properly and be able to get the code into the main development tree. I just need a push in the right direction, architecture wise ... is this is the only way to do it (ie creating another global variable in mh)? Should a database interface module be created as a library and then instances created just like the JR21A for each call? Can a global variable for the connection be created in a library and then used everywhere else (web/code)? While MySQL is lightning fast with login processing I am loathe to set it up so that every SQL query needs login commands prepared before the query is executed. Thanks Denis. |