| | 387 | |
| | 388 | === 1/18/2011 === |
| | 389 | |
| | 390 | I've made a couple of big changes. |
| | 391 | * there is now a device sub class of component which network and usb should be subclasses of. |
| | 392 | It implements the get_device_kind method which takes the identifying numbers and search for the device_kind, if the kind is missing, it will insert it |
| | 393 | into the table and then pull the kind_id back from the table. |
| | 394 | * It could be argued that the current implementation of get_device_kind requires too many parameters (vendor, device, desc, bus, inv_id), but I can't think |
| | 395 | of a cleaner way to pass that information, they're all device dependant. |
| | 396 | * heavily modified the update method on network class. It pulls an array of arrays (1 for each interface) from sql via an map(sql_query()) call, it then form a similarly |
| | 397 | structured gathered array (which uses the newly implemented get_device_kind method). I use a collection of zips and maps to compare the arrays and make an array |
| | 398 | of booleans 1 for each interface. Since I'm using the Array.eql? method to determine if the "data" matches, the match array is type safe because it will always get a |
| | 399 | bool. Even if the sql data matrix is empty. Using the match array I zip the collected information and then push updates and inserts as necessary. |
| | 400 | * to make the checks happen I stick with array most of the way down, and only "cast" to a hash if I need to pass a parameter. I use hashes in both insert and update |
| | 401 | for uniformity. Really insert could be done properly with 2 array, instead of a hash (thats the way it's used internally any way), but the interface is less cryptic |
| | 402 | and the hash processing is done with maps and zips (on the keys array) so it not much diffrent. In the update method I actually use the hash structure. |
