On Wed, 2008-04-09 at 10:20 -0500, Chris Weiss wrote: > On Wed, Apr 9, 2008 at 10:10 AM, Benoit Hamet <[EMAIL PROTECTED]> wrote: > > solve the problem, which let me think about a reentrant problem (so a > > new query is done using the same db object, and so next_record() is > > totaly wrong next time ...). > > > > I Guess we already discuss this [Yeah : search for "Is there some > > problem using adodb?" in 2005 archives] ... but do we have an "elegant" > > solution for this kind of problem ? > > clone the db object in the sonotes ? (beurk) > > perhaps better, let accounts having it's own cloned db object (little > > better, since like that it won't hurt when using ldap as backend). > > avoid this kind of code ? :) > > > > I'd go for the latter. if we could always lookup the name int eh db > i'd go with adding a JOIN to the first query, but if that won't work > with ldap, then having the accounts class self contained is the better > option. > > however, with adodb we can make it reentrant, just that the old db > class that wraps it wasn't designed that way.
I think it is best to make the db object a singleton and use PDO, but I don't think that will happen in this release. I think we are stuck with the same circa 1999 design from PHPLib for this release. Cloning the db object is not sustainable. I have seen cases where we have had more than 10 db objects created for rendering 1 simple list of records. This chews up a lot of resources and memory on the server. Cheers Dave _______________________________________________ phpGroupWare-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
