Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
keeping arrays and databases consistent?

Posted by that_guy (that_guy), 1 August 2003
hi. I'm working on a program that stores and launches hardware configurations and programs.  My programs saves information on three levels. When it first starts up, it grabs current information from the hardware and sticks it into arrays and lists.  As the user now modifies settings, the changes are recorded only in the arrays and lists. When the user wants to save the changes, they use a save option from the file menu and the changes are written to a database. When the user opts finally opts to commit the changes they are  sent from the database to the hardware.  The way I've written this right now is a mess of for loops and if exists checks. Do you have any thoughts on an alternate approach, perhaps writing the changes I currently write to arrays into a temporary database table instead, and then when a user saves, insert records into the primary table? I'm not sure if comparing existing values might be easier this way. An example of the current monstrosity(riddled with debugging statements):
#Adding ports,vlans,programs to database
   foreach vl [::libextreme::get_vlans offline] {
       foreach prt [::libextreme::get_vlan_ports $vl offline] {
           set db_ports [mysqlsel $fh "select port from vlans where exp_name='$exp_name' and vlan_name='$vl'" -list]
           #if port already exists in database and in memory
           #do nothing
           if {[lsearch $db_ports $prt] > 0} {
               continue
           } else {
               #if exists in memory but not in db, insert
               #mysqlexec $fh "insert into vlans(exp_name,vlan_name,port) values ('$exp_name','$vl','$prt')"
               send_user "insert into vlans(exp_name,vlan_name,port) values ('$exp_name','$vl','$prt')\n"
           }

           set crnthost [mysqlsel $fh "select host1 from cable_config where concat_ws(':',interface2,port2)='$prt'" -flatlist]
           if {![catch {info exists $::libextreme::programs($crnthost)} err]} {
               foreach pr $::libextreme::programs($crnthost) {
                   #mysqlexec $fh "insert into host_to_prog(exp_name,host_name,prog_name,params,seq_number) values('$exp_name','$crnthost','[lindex $pr 0]','[lindex $pr 1]' , $seq)"
                   send_user "insert into host_to_prog(exp_name,host_name,prog_name,params,seq_number) values ('$exp_name','$crnthost','[lindex $pr 0]','[lindex $pr 1 ]',$seq)\n"
                   incr seq
               }
           } else {send_user "$err: DOESN'T EXIST!!!*****\n"}



Posted by admin (Graham Ellis), 2 August 2003
If you feel that a program's becoming a monstrosity (or likely to do so) - a mess of loops and conditional checks - the best approach is often to "divide and conquer".

Split the code into a series of chunks, each of which performs a single logical operation (such as "save array to database") in perhaps 10 to 15 lines of code (that's an elatic length), call the block a "proc", pass in and return parameters, and shorten your main code by the length of the proc.   Does wonders for clarity, and in itself the operation really helps you sort our design issues.  Then you find that the same procs are useful in your other programs too, and so you're rewarded twice over.

Second suggestion - state variables.  If you find yourself writing complex logicals, especially where you keep re-running a similar test (e.g. a and b and c, then later a and b and d), save the common part of the test into a variable (e.g. set j a and b) and then simplify your other tests (j and c, later j and d in my example).

With a GUI based appliaction such as yours, state variables become very important and can be at the crux of the design; draw diagrams to help yourself showing how the systtem moved from state to state ....

It's never quick and easy to read someone's spec on this board and come up with a magic answer, but I look at your description and feel that I would structure the application around an array of state variables - one for each piece of hardware currently in your selection menu.   State 0 - nothing defined.  State 1 - temporary changes made.  State 2 - data saved to database. State 3 - data sent back out to hardware.  State 4 - hardware kicked to tell it to read changes file.  Selection logic and visual indicators become easy, and you have 4 logical slits for the procs to divide your code.

Hope this makes sense ... hope I'm somewhat answering the right question.   "When should I save to database" should tend to answer itself as you clarify your design, and if you find as you're designing of coding that a slight change is probably needed, you've got the structure in your code to do so easily.



This page is a thread posted to the opentalk forum at www.opentalk.org.uk and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho