DBIx::SB::Handle -- $PrevHandle question

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,

  • Dmitri.
  1. 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,

  • Dmitri.
  1. 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:

  1. Get handle ABC ($PrevHandle now points to ABC);

  2. Get handle DEF ($PrevHandle now points to DEF);

  3. ABC gets disconnected (ping times out or what-not – haven’t
    researched exactly how it gets undefed yet).

  4. 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?

  • Dmitri.

Jesse Vincent wrote:

Here’s my situation:

  1. Get handle ABC ($PrevHandle now points to ABC);

  2. Get handle DEF ($PrevHandle now points to DEF);

  3. ABC gets disconnected (ping times out or what-not – haven’t
    researched exactly how it gets undefed yet).

  4. 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 :slight_smile:

Thank you,

  • Dmitri.

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.

  • Dmitri.

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 :wink:

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…

  • Dmitri.

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?

  • Dmitri.

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.