Re: [phpGroupWare-developers] is the db class reentrant ? (following an old post of sigurd in 2005)

[Chris Weiss]

On Wed, Apr 9, 2008 at 5:31 PM, Dave Hall <address@hidden> wrote:
> On Wed, 2008-04-09 at 10:20 -0500, Chris Weiss wrote:
>  > On Wed, Apr 9, 2008 at 10:10 AM, Benoit Hamet <address@hidden> 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

right, I was speaking "for the short term".  fixing it the right way
would be a rather major change, and we don't don't need any of that
right now.