Dear RTers and DBIx::SBers,
what is the purpose of $PrevHandle “magic” in
DBIx::SearchBuilder::Handle? Specifically, this code:
sub dbh {
my $self=shift;
#If we are setting the database handle, set it.
$DBIHandle{$self} = $PrevHandle = shift if (@_);
return($DBIHandle{$self} ||= $PrevHandle);
}
puzzles me. The conversion from $DBIHandle to %DBIHandle is based on
patch from Audrey Tang [1] which was included along with $PrevHandle
into the 0.61 → 0.96 changeset [2]. However, I can’t find the
explanation for $PrevHandle in the Changes file or anywhere in the
comments. Could someone please tell me why it’s there?
Thank you,
- Bug #4167 for DBIx-SearchBuilder: [PATCH] allow more than one Handle object
-
http://search.cpan.org/diff?from=DBIx-SearchBuilder-0.61&to=DBIx-SearchBuilder-0.96
Dear RTers and DBIx::SBers,
what is the purpose of $PrevHandle “magic” in
DBIx::SearchBuilder::Handle? Specifically, this code:
sub dbh {
my $self=shift;
#If we are setting the database handle, set it.
$DBIHandle{$self} = $PrevHandle = shift if (@_);
return($DBIHandle{$self} ||= $PrevHandle);
}
puzzles me. The conversion from $DBIHandle to %DBIHandle is based on
patch from Audrey Tang [1] which was included along with $PrevHandle
into the 0.61 → 0.96 changeset [2]. However, I can’t find the
explanation for $PrevHandle in the Changes file or anywhere in the
comments. Could someone please tell me why it’s there?
Thank you,
- http://rt.cpan.org/Public/Bug/Display.html?id=4167
-
http://search.cpan.org/diff?from=DBIx-SearchBuilder-0.61&to=DBIx-SearchBuilder-0.96
Dear RTers and DBIx::SBers,
what is the purpose of $PrevHandle “magic” in
DBIx::SearchBuilder::Handle? Specifically, this code:
sub dbh {
my $self=shift;
#If we are setting the database handle, set it.
$DBIHandle{$self} = $PrevHandle = shift if (@_);
return($DBIHandle{$self} ||= $PrevHandle);
}
puzzles me. The conversion from $DBIHandle to %DBIHandle is based on
patch from Audrey Tang [1] which was included along with $PrevHandle
into the 0.61 → 0.96 changeset [2]. However, I can’t find the
explanation for $PrevHandle in the Changes file or anywhere in the
comments. Could someone please tell me why it’s there?
I believe that this made SB able to handle a temporary dbh change if you
needed to open a new handle, work and then go back to what you were
doing.
Here’s my situation:
-
Get handle ABC ($PrevHandle now points to ABC);
-
Get handle DEF ($PrevHandle now points to DEF);
-
ABC gets disconnected (ping times out or what-not – haven’t
researched exactly how it gets undefed yet).
-
Then this code: $ABC->dbh will return DEF handle because of
this:
return($DBIHandle{$self} ||= $PrevHandle);
This behavior of SB::Handle is undocumented, surprising and I think it
is actually a bug.
Is that $PrevHandle still relied on in RT or is it a relic?
Jesse Vincent wrote:
Here’s my situation:
-
Get handle ABC ($PrevHandle now points to ABC);
-
Get handle DEF ($PrevHandle now points to DEF);
-
ABC gets disconnected (ping times out or what-not – haven’t
researched exactly how it gets undefed yet).
-
Then this code: $ABC->dbh will return DEF handle because of
this:
return($DBIHandle{$self} ||= $PrevHandle);
This behavior of SB::Handle is undocumented, surprising and I think it
is actually a bug.
Is that $PrevHandle still relied on in RT or is it a relic?
It’s not something that can be removed, no. Patches to address the issue
you’re running into would be welcome, though
Jesse Vincent wrote:> On Wed, Feb 21, 2007 at 04:41:54PM -0500, Dmitri Tikhonov wrote:
Is that $PrevHandle still relied on in RT or is it a relic?
It’s not something that can be removed, no.
Could you please elaborate on that? Since we maintain an instance of RT
here, this dependence on $PrevHandle interests me. In what way does RT
depend on this behavior?
(I could remove it and wait for something to break, but I think that’s a
suboptimal solution if you just know why it’s needed
Thank you,
Jesse Vincent wrote:
Is that $PrevHandle still relied on in RT or is it a relic?
It’s not something that can be removed, no.
Could you please elaborate on that? Since we maintain an instance of RT
here, this dependence on $PrevHandle interests me. In what way does RT
depend on this behavior?
RT isn’t the only application that uses DBIx::SearchBuilder. Just
because a feature has a bug for you doesn’t mean that the right answer
is “just remove it”
Jesse Vincent wrote:
RT isn’t the only application that uses DBIx::SearchBuilder. Just
because a feature has a bug for you doesn’t mean that the right answer
is “just remove it”
That is true. But I think this behavior should at least be documented.
Anyone using DBIx::SearchBuilder to connect to more than one database
has a ticking bomb on their hands.
Jesse Vincent wrote:
RT isn’t the only application that uses DBIx::SearchBuilder. Just
because a feature has a bug for you doesn’t mean that the right answer
is “just remove it”
That is true. But I think this behavior should at least be documented.
Anyone using DBIx::SearchBuilder to connect to more than one database
has a ticking bomb on their hands.
Patches most welcome. As are failing tests. (And a failing test is a
great way to push the work to somebody else
Jesse,
I can’t really fix it if I don’t know what $PrevHandle is for and how RT
(and maybe other projects) depend on the peculiar behavior it provides.
If we can’t find the answer to that, I suggest that POD be updated…
Jesse Vincent wrote:
Jesse,
I can’t really fix it if I don’t know what $PrevHandle is for and how RT
(and maybe other projects) depend on the peculiar behavior it provides.
If we can’t find the answer to that, I suggest that POD be updated…
It allows you to set $handle->dbh to something, work and then undef it
and step back to the previous handle, possibly many handles deep.
Jesse Vincent wrote:
Jesse,
I can’t really fix it if I don’t know what $PrevHandle is for and how RT
(and maybe other projects) depend on the peculiar behavior it provides.
If we can’t find the answer to that, I suggest that POD be updated…
It allows you to set $handle->dbh to something, work and then undef it
and step back to the previous handle, possibly many handles deep.
Does RT use that behavior somewhere?
It allows you to set $handle->dbh to something, work and then undef it
and step back to the previous handle, possibly many handles deep.
Does RT use that behavior somewhere?
I do not believe it does, currently.