RE: [phpGroupWare-developers] Nested db-objects

[Sigurd Nes]

> From: Dave Hall address@hidden
> Sent: 2008-05-22 01:46:56 CEST
> To: address@hidden
> Subject: Re: [phpGroupWare-developers] Nested db-objects
> 
> On Wed, 2008-05-21 at 20:02 +0200, Sigurd Nes wrote:
> > Hi all,
> > 
> > I find it very useful to have the ability to have the choice of using 
> > nested 
> > db-objects.
> > 
> > Example:
> > When integrating with external systems - it is very convenient to start a 
> > transaction on system 1 - do some work (like sync) on system 2 - and if 
> > things 
> > went well do a commit on the result in system 1.
> 
> In this case (connecting to an external system) you are working outside
> the scope the db abstraction layer.  In this case you can create a
> separate connection using adodb directly.
> 
> 
> > To make this work there is a need for two tiny changes in the 
> > class.db.inc.php:
> > 
> > 1) on line 133 in the function __clone():
> > 
> > change      
> >     $this->new_adodb();
> > to
> >     $this->adodb = clone($this->adodb);
> > 
> > 2) Also the new function __destruct() - which do a disconnect has to be 
> > commented
> 
> When the database object is destroyed the connection should be closed.
> This is a basic resource management issue.
> 
> > How about it?
> 

lol - here we go again :)

> This isn't a tiny change.  It is a major change.  

I think its a tiny change to change it back - this was silently introduced 
without any proper discussion - and the consequences was not apparent at the 
time.  

> 
> The discussion about multiple database objects has come up several times
> recently and the outcome has been that the db object should be treated
> like a singleton.  It gets rather boring having the same discussions
> over and over again when the underlying facts haven't changed.

Well - is this the common consensus of the community? - its not clear to me.

> Your proposal undermines such an approach.  I think in 18+1 we should
> make __clone a private method which would prevent cloning, and for 18
> make it trigger a notice when called.

I'm beginning to doubt that there will ever be a 18 - since the attitude seems 
to be 'ready when ready' - and sudden constraints are imposed that breaks the 
system - and calls for serious rework of existing working code.

> 
> When working on the current trunk code base I have found many needless
> clones, for stupid things like counting records, rather than simply
> executing queries in a better sequence.  Many other times it is because
> too much logic is placed in the storage layer.  Storage classes are
> responsible for _storage_, not busisness logic, combining data is the
> role of bo layer which is responsible for _logic_.

Of course there are stupid things (you might even call it crap) - but we cant 
really rewrite the whole code all the time.
The code is working - and we need one foot on the ground.

> 
> Except in the case of connecting to external systems, there should be no
> need to clone the db object.  If there is then your design is probably
> broken.

Well - I respectfully disagree :)

Regards

Sigurd