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
