DBDO's slow migration from vapourware to bugware has been progressing this week. A month ago, I started useability testing on the PHP5 version of this site, and it helped find alot more issues than the unit tests that I had set up.
A few weeks ago though, I was working on another application that uses a threaded version of PHP embed, and DBDO, which was throwing up quite a few bugs around setting / fetching data using the overloaded internal setters and getters.
The original design of DBDO, was that when you fetch a value (eg.)
echo $do->name;
that the object would internally get the value from libgda at this point, rather than the way DB_DataObject currently does, by assigning all the PHP variables when you call $do->fetch().
The trouble was that this way of working began to get very confusing when mixed with all the potential ways that you may access the data.
- Setting the column value (at this point you have to store a seperate hash for assigned values)
- print_r and it's like need you to actually set values for all the properties.
I ended up with something like 3 hashes doing various tasks, and each needing memory managing. And as usual, complexity leads to numerous bugs.. So I made the decision last week to follow DataObjects logic of simply setting the properties on fetch().
This removed a large chunk of code, and in general simpified the whole query building process. Things like the update code could easily compare the fetched data against the current object properties and update only the changed data. The only thing that caught me out was that unless you add a zend_objects_store_add_ref() after changing the properties internally, the values get free'd too early and segfaults occur.
Anyway, the current plan is to get back to testing the code on the PHP5 version of this site next week, then actually make an alpha release...
