> From: Dave Hall [EMAIL PROTECTED] > Sent: 2008-05-22 01:46:56 CEST > To: [email protected] > 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
_______________________________________________ phpGroupWare-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
