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 2021 - online Python 3 training - see ((here)).

Our plans were to retire in summer 2020 and see the world, but Coronavirus has lead us into a lot of lockdown programming in Python 3 and PHP 7.
We can now offer tailored online training - small groups, real tutors - works really well for groups of 4 to 14 delegates. Anywhere in the world; course language English.

Please ask about private 'maintenance' training for Python 2, Tcl, Perl, PHP, Lua, etc.
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} {
           } 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 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., 2022: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: • WEB: • SKYPE: wellho