I have an issue with proper usage of swap_inner_handle:
Say I have a dbh with an active sth.
I create a new dbh (new_dbh) and swap its inner handle with dbh.
Now is sth a child of dbh or new_dbh? i.e., is sth linked to the
inner dbh, or not at all?
Then I create a new sth (new_sth) and swap its inner handle with sth.
What happens?
Thanks,
H
On Wed, Oct 04, 2006 at 11:53:48AM -0700, Henri Asseily wrote:
> I have an issue with proper usage of swap_inner_handle:
>
> Say I have a dbh with an active sth.
> I create a new dbh (new_dbh) and swap its inner handle with dbh.
>
> Now is sth a child of dbh or new_dbh? i.e., is sth linked to the
> inner dbh, or not at all?
It remains linked with the original inner dbh which has been swapped
into new_dbh.
> Then I create a new sth (new_sth) and swap its inner handle with sth.
Is the new sth created from dbh or new_dbh?
> What happens?
The sth will be a child of the (inner) dbh you used to create it.
[It's clear that the lack of a terminology/nomenclature makes it harder
to think about and discuss what's happening.]
Since you ask the question I assume you may have a problem.
Looking at the code I can see one potential issue...
Handles include a reference to their parent's _outer_ handle.
The code doesn't do anything about that but should in two cases:
1. If the parents of the handles being swapped differ, and the
allow_reparent parameter is true.
2. Any existing child handles of the two handles being swapped
should have their parent handle references updated.
I'll assume the second one is the cause of the problem I'm assuming you have.
As far as I can tell from a quick look, that would affect:
- How the Statement attribute gets copied from sth to parent dbh.
- How the 'last used handle' is updated by DESTROY
Are my assumptions correct?
Tim.
On Oct 5, 2006, at 6:19 AM, Tim Bunce wrote:
> On Wed, Oct 04, 2006 at 11:53:48AM -0700, Henri Asseily wrote:
>> I have an issue with proper usage of swap_inner_handle:
>>
>> Say I have a dbh with an active sth.
>> I create a new dbh (new_dbh) and swap its inner handle with dbh.
>>
>> Now is sth a child of dbh or new_dbh? i.e., is sth linked to the
>> inner dbh, or not at all?
>
> It remains linked with the original inner dbh which has been swapped
> into new_dbh.
Ok.
>
>> Then I create a new sth (new_sth) and swap its inner handle with sth.
>
> Is the new sth created from dbh or new_dbh?
It's created from dbh, but after it was swapped with new_dbh (i.e.
it's created with the outer dbh and inner new_dbh).
>
>> What happens?
>
> The sth will be a child of the (inner) dbh you used to create it.
Ok so now sth and new_sth are children of the same inner dbh, and no
reparenting is being done when I swap them.
>
> [It's clear that the lack of a terminology/nomenclature makes it
> harder
> to think about and discuss what's happening.]
My thoughts exactly :)
>
> Since you ask the question I assume you may have a problem.
> Looking at the code I can see one potential issue...
>
> Handles include a reference to their parent's _outer_ handle.
> The code doesn't do anything about that but should in two cases:
> 1. If the parents of the handles being swapped differ, and the
> allow_reparent parameter is true.
> 2. Any existing child handles of the two handles being swapped
> should have their parent handle references updated.
>
> I'll assume the second one is the cause of the problem I'm assuming
> you have.
> As far as I can tell from a quick look, that would affect:
> - How the Statement attribute gets copied from sth to parent dbh.
> - How the 'last used handle' is updated by DESTROY
>
> Are my assumptions correct?
It was less of seeing a problem, and more of "what is the One True
Way of using swap_inner_handle":
I have dbh with sth, then I create new_dbh and swap with dbh. I then
create new_sth and swap with sth.
Then I undef'd new_sth and new_dbh.
From what you're saying, because I get rid of new_dbh and new_sth
that were "polluted", I shouldn't be hit with the 2 issues you're
talking about.
(For those who wonder what we're talking about, playing this game
allows one to reconnect and reexecute a statement with the requesting
code knowing nothing about what's being done. It thinks it executed a
statement successfully when in fact "the shit hit the fan" in the
backend, and we had to connect to a new database and reexecute the
statement)
H
On Thu, Oct 05, 2006 at 12:21:17PM -0700, Henri Asseily wrote:
> On Oct 5, 2006, at 6:19 AM, Tim Bunce wrote:
>
> >>Say I have a dbh with an active sth.
> >>I create a new dbh (new_dbh) and swap its inner handle with dbh.
> >>
> >>Now is sth a child of dbh or new_dbh? i.e., is sth linked to the
> >>inner dbh, or not at all?
> >
> >It remains linked with the original inner dbh which has been swapped
> >into new_dbh.
>
> Ok.
>
> >>Then I create a new sth (new_sth) and swap its inner handle with sth.
> >
> >Is the new sth created from dbh or new_dbh?
>
> It's created from dbh, but after it was swapped with new_dbh (i.e.
> it's created with the outer dbh and inner new_dbh).
>
> >>What happens?
> >
> >The sth will be a child of the (inner) dbh you used to create it.
>
> Ok so now sth and new_sth are children of the same inner dbh, and no
> reparenting is being done when I swap them.
>
> >[It's clear that the lack of a terminology/nomenclature makes it
> >harder to think about and discuss what's happening.]
>
> My thoughts exactly :)
Let's try this and see how it works out:
Original state:
dbh1o -> dbh1i
sthAo -> sthAi(dbh1i)
dbh2o -> dbh2i
swap_inner_handle dbh1o with dbh2o:
dbh2o -> dbh1i
sthAo -> sthAi(dbh1i)
dbh1o -> dbh2i
create new sth from dbh1o:
dbh2o -> dbh1i
sthAo -> sthAi(dbh1i)
dbh1o -> dbh2i
sthBo -> sthBi(dbh2i)
swap_inner_handle sthAo with sthBo:
dbh2o -> dbh1i
sthBo -> sthAi(dbh1i)
dbh1o -> dbh2i
sthAo -> sthBi(dbh2i)
Does that fit your expectations?
> >Since you ask the question I assume you may have a problem.
> >Looking at the code I can see one potential issue...
> >
> >Handles include a reference to their parent's _outer_ handle.
> >The code doesn't do anything about that but should in two cases:
> >1. If the parents of the handles being swapped differ, and the
> > allow_reparent parameter is true.
> >2. Any existing child handles of the two handles being swapped
> > should have their parent handle references updated.
> >
> >I'll assume the second one is the cause of the problem I'm assuming
> >you have.
> >As far as I can tell from a quick look, that would affect:
> > - How the Statement attribute gets copied from sth to parent dbh.
> > - How the 'last used handle' is updated by DESTROY
> >
> >Are my assumptions correct?
>
> It was less of seeing a problem, and more of "what is the One True
> Way of using swap_inner_handle":
> I have dbh with sth, then I create new_dbh and swap with dbh. I then
> create new_sth and swap with sth.
> Then I undef'd new_sth and new_dbh.
> From what you're saying, because I get rid of new_dbh and new_sth
> that were "polluted", I shouldn't be hit with the 2 issues you're
> talking about.
I think you're okay because you don't do anything with the old handles
(except destroy them).
Tim.
> (For those who wonder what we're talking about, playing this game
> allows one to reconnect and reexecute a statement with the requesting
> code knowing nothing about what's being done. It thinks it executed a
> statement successfully when in fact "the shit hit the fan" in the
> backend, and we had to connect to a new database and reexecute the
> statement)
>
> H
>
--------------080304070205080501000902
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Tim Bunce wrote:
>On Thu, Oct 05, 2006 at 12:21:17PM -0700, Henri Asseily wrote:
>
>
>>On Oct 5, 2006, at 6:19 AM, Tim Bunce wrote:
>>
>>
>>
>>>>Say I have a dbh with an active sth.
>>>>I create a new dbh (new_dbh) and swap its inner handle with dbh.
>>>>
>>>>Now is sth a child of dbh or new_dbh? i.e., is sth linked to the
>>>>inner dbh, or not at all?
>>>>
>>>>
>>>It remains linked with the original inner dbh which has been swapped
>>>into new_dbh.
>>>
>>>
>>Ok.
>>
>>
>>
>>>>Then I create a new sth (new_sth) and swap its inner handle with sth.
>>>>
>>>>
>>>Is the new sth created from dbh or new_dbh?
>>>
>>>
>>It's created from dbh, but after it was swapped with new_dbh (i.e.
>>it's created with the outer dbh and inner new_dbh).
>>
>>
>>
>>>>What happens?
>>>>
>>>>
>>>The sth will be a child of the (inner) dbh you used to create it.
>>>
>>>
>>Ok so now sth and new_sth are children of the same inner dbh, and no
>>reparenting is being done when I swap them.
>>
>>
>>
>>>[It's clear that the lack of a terminology/nomenclature makes it
>>>harder to think about and discuss what's happening.]
>>>
>>>
>>My thoughts exactly :)
>>
>>
>
>Let's try this and see how it works out:
>
>Original state:
> dbh1o -> dbh1i
> sthAo -> sthAi(dbh1i)
> dbh2o -> dbh2i
>
>swap_inner_handle dbh1o with dbh2o:
> dbh2o -> dbh1i
> sthAo -> sthAi(dbh1i)
> dbh1o -> dbh2i
>
>create new sth from dbh1o:
> dbh2o -> dbh1i
> sthAo -> sthAi(dbh1i)
> dbh1o -> dbh2i
> sthBo -> sthBi(dbh2i)
>
>swap_inner_handle sthAo with sthBo:
> dbh2o -> dbh1i
> sthBo -> sthAi(dbh1i)
> dbh1o -> dbh2i
> sthAo -> sthBi(dbh2i)
>
>Does that fit your expectations?
>
>
>
>>>Since you ask the question I assume you may have a problem.
>>>Looking at the code I can see one potential issue...
>>>
>>>Handles include a reference to their parent's _outer_ handle.
>>>The code doesn't do anything about that but should in two cases:
>>>1. If the parents of the handles being swapped differ, and the
>>> allow_reparent parameter is true.
>>>2. Any existing child handles of the two handles being swapped
>>> should have their parent handle references updated.
>>>
>>>I'll assume the second one is the cause of the problem I'm assuming
>>>you have.
>>>As far as I can tell from a quick look, that would affect:
>>>- How the Statement attribute gets copied from sth to parent dbh.
>>>- How the 'last used handle' is updated by DESTROY
>>>
>>>Are my assumptions correct?
>>>
>>>
>>It was less of seeing a problem, and more of "what is the One True
>>Way of using swap_inner_handle":
>>I have dbh with sth, then I create new_dbh and swap with dbh. I then
>>create new_sth and swap with sth.
>>Then I undef'd new_sth and new_dbh.
>>From what you're saying, because I get rid of new_dbh and new_sth
>>that were "polluted", I shouldn't be hit with the 2 issues you're
>>talking about.
>>
>>
>
>I think you're okay because you don't do anything with the old handles
>(except destroy them).
>
>Tim.
>
>
>
>>(For those who wonder what we're talking about, playing this game
>>allows one to reconnect and reexecute a statement with the requesting
>>code knowing nothing about what's being done. It thinks it executed a
>>statement successfully when in fact "the shit hit the fan" in the
>>backend, and we had to connect to a new database and reexecute the
>>statement)
>>
>>H
>>
>>
>>
Another usage of the same technique: synchronization of two databases
which requires two passes, in two directions. Swapping db handles, we
can use the same set of previously prepared queries without reconnecting
for the second pass. That way, the code is cleaner and the very
synchronisation is faster.
Just my two cents.
V.
--------------080304070205080501000902--
On Oct 5, 2006, at 4:39 PM, Tim Bunce wrote:
>
> Let's try this and see how it works out:
>
> Original state:
> dbh1o -> dbh1i
> sthAo -> sthAi(dbh1i)
> dbh2o -> dbh2i
>
> swap_inner_handle dbh1o with dbh2o:
> dbh2o -> dbh1i
> sthAo -> sthAi(dbh1i)
> dbh1o -> dbh2i
>
> create new sth from dbh1o:
> dbh2o -> dbh1i
> sthAo -> sthAi(dbh1i)
> dbh1o -> dbh2i
> sthBo -> sthBi(dbh2i)
>
> swap_inner_handle sthAo with sthBo:
> dbh2o -> dbh1i
> sthBo -> sthAi(dbh1i)
> dbh1o -> dbh2i
> sthAo -> sthBi(dbh2i)
>
> Does that fit your expectations?
Any way is fine with me, as long as it's clear. :-)
The above is what I understood was happening, from your earlier
email. I'm good, thanks.
H