Re: [phpGroupWare-developers] Nested db-objects

[Benoit Hamet]

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.
Agreed.


>>
>>
>>> 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.
Clearly.

>>
>>> 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.
In my case, the db should be made singleton. That's clear.

> 
>> 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.
At the time, I avoid working with the account system, since I'm waiting
for some "bugs already fixed somewhere", and don't want to lose time
fixing them again ... 18 will be there when people will understand that
having a solid base of good code will help us to 1) work better in the
future 2) get more dev involved .... so yes ready when ready. Can you
please put there what you call "sudden constraints are imposed that
breaks the system". I don't want to read here, changes that were made
and rolled back for sanity reasons.


> 
>> 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.
So people can continue with writing bad code ??? Making it even more
difficult to migrate ? And btw, telling that "code is working" make me
caught.

> 
>> 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 :)
Me too.

Regards.

Caeies.