[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [phpGroupWare-developers] Nested db-objects
From: |
Dave Hall |
Subject: |
Re: [phpGroupWare-developers] Nested db-objects |
Date: |
Thu, 22 May 2008 09:46:56 +1000 |
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?
This isn't a tiny change. It is a major change.
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.
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.
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_.
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.
Cheers
Dave
--
Dave Hall (aka skwashd)
Coordinator - Community Building
phpGroupWare
e address@hidden
w phpgroupware.org
j address@hidden
sip address@hidden
_ ____ __ __
_ __ | |__ _ __ / ___|_ __ ___ _ _ _ _\ \ / /_ _ _ __ ___
| '_ \| '_ \| '_ \| | _| '__/ _ \| | | | '_ \ \ /\ / / _` | '__/ _ \
| |_) | | | | |_) | |_| | | | (_) | |_| | |_) \ V V / (_| | | | __/
| .__/|_| |_| .__/ \____|_| \___/ \__,_| .__/ \_/\_/ \__,_|_| \___|
|_| |_| |_|Web based collaboration platform
- [phpGroupWare-developers] Nested db-objects, Sigurd Nes, 2008/05/21
- Re: [phpGroupWare-developers] Nested db-objects,
Dave Hall <=
- RE: [phpGroupWare-developers] Nested db-objects, Sigurd Nes, 2008/05/22
- Re: [phpGroupWare-developers] Nested db-objects, Maât, 2008/05/22
- Re: [phpGroupWare-developers] Nested db-objects, Dr. Christian Böttger, 2008/05/23
- Re: [phpGroupWare-developers] Nested db-objects, Maât, 2008/05/23
- RE: [phpGroupWare-developers] Nested db-objects, Sigurd Nes, 2008/05/24
- RE: [phpGroupWare-developers] Nested db-objects, Dave Hall, 2008/05/24
- RE: [phpGroupWare-developers] Nested db-objects, Sigurd Nes, 2008/05/24
- Re: [phpGroupWare-developers] Nested db-objects, Maât, 2008/05/24