Re: SV: [phpGroupWare-developers] Nested db-objects

[Dave Hall]

On Thu, 2008-05-22 at 17:46 +0200, Sigurd Nes wrote:
> Dave Hall wrote:
> > On Thu, 2008-05-22 at 15:06 +0200, Sigurd Nes wrote:
> >>> From: Olivier Berger address@hidden
> >>> Sent: 2008-05-22 13:35:48 CEST
> >>> To: address@hidden
> >>> Subject: Re: [phpGroupWare-developers] Nested db-objects
> >>>
> >>> Le mercredi 21 mai 2008 à 20:02 +0200, Sigurd Nes a écrit :
> >>>> 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.
> >>>>
> >>> Sure.
> >>>
> >>> Are there any test cases to verify that such frameworks are working as
> >>> expected in phpgw ?
> >> Her is one example on how I have used nested db-objects:
> >> I have a configurable hierarchy of locations (read: 
> >> estate/building/floor/room etc)
> >> Within each level (which is represented by a set of tables) one can have 
> >> custom fields of any type.
> >> This function allows you to delete the bottom level and cleaning out the 
> >> custom fields from the meta database in the process.
> >>
> >> <code>
> >> function delete($id)
> >> {
> >>    $this->init_process();
> >>    $this->oProc->m_odb->transaction_begin();
> >>    $this->db->transaction_begin();
> > 
> > Wouldn't it be cleaner to have $this->oProc->m_odb as a reference
> > to $this->db which is a reference to $GLOBALS['phpgw']->db then you
> > only need to call transaction_begin() once and have only one transaction
> > running?
> > 
> The point is that this approach has been valid for years - and this approach 
> is 
> used numerous places - and it will be a major setback if it is suddenly 
> banned.

It is now clear that the "connecting to a different database example"
you used as a justification for this requirement wasn't the real reason
for asking for the change.

It was only done that way as it was the default PHP4 behaviour.  PHP5
isn't PHP4.  It was broken design back then and it is broken design now.

Things get fixed over time, and old hacks cease to work, that is the
nature of development.  If the API didn't evolve over the last 4 years
then that would be a bigger problem, imho.

> Why can't we do as Maât suggest - and we should all be happy:

Because it is still broken.  We shouldn't be rolling back changes which
improve the code base because one person doesn't want to move forward.  

I discussed this with Pascal last night.  We agreed that the API should
be easy to use and hard to abuse - see Rusty Russell's blog post of this
topic [1].  When Pascal posted this he was not aware that with current
trunk it is possible to have 10+ instances of the db object active at
once.  For now Pascal supports leaving the code as is until there is a
better solution which handles resource management properly.  I hope I
have summarised the discussion properly.

Cheers

Dave

[1] http://ozlabs.org/~rusty/index.cgi/2008/03/18