This post originated from an RSS feed registered with PHP Buzz
by Alan Knowles.
Original Post: DBDO status update - zend object internals
Feed Title: Smoking toooo much PHP
Feed URL: http://www.akbkhome.com/blog.php/RSS.xml
Feed Description: More than just a blog :)
Just before Christmas, I ran into another roadblock with DBDO. one of those problems that you know isn't going to be fixed quickly, so you pospone it until you really have a bit of free time to solve it.
This particular issue was partly brought on by trying to implement sleep/serialization, but had cropped up before and I tried to ignore it - however sleep/serialization basicaly forced it to be addressed.
A 'post-query' DBDO objects represents an row of the database, if you modify the values, it is supposed to store the seperatly so that it knows you modified them. Hence when you update an object, it can work out what has changed an build a nice effecient query.. This makes the read_property and properties_get methods a little complex (as it has to decide if you asked for a property which is returned from the database or one you assigned afterwards.)
Unfortunatly, the read and write access to object properties in PHP's internals is a little haphazard. (funnily enough it appears to violate all data encapsulation ideas that OO principles are supposed to encourage - and that DBDO's direct access usage also breaks.)
A normal PHP object instance stores all it's properties in a single hash table. Access for writing and reading this hash is not strictly enforced (eg. by always using get/set properties on the object) , and many parts of PHP's internals write and read directly from it.
This has been causes all sorts of problems when attempting to decide if something has been changed, and hence should be updated.
functions like print_r() access the access the get_properties method of the object, however it also appears it might assign the objects properties to the returned value... however serialization calls the __sleep method, then access the property hash directly, rather than using either the objects property_get or get_properties internal methods.
Add to this, the uncertainty that zvals returned from get_properties may not actually be free'd or dtor'd (so as far as I could tell, i have to store the return value of get_properties and hash_destroy it at object destruct time..) makes the whole clever object storage stuff a little more complex that initially envisioned.
But hopefull a first beta should be out by the end of january, when I'll see if I can reduce the 3 hashtables that a DBDO object stores internally a little.
Previous Topic
