PATCH DBIx::SearchBuilder

This patch for DBIx::SB allows you to do a LEFT JOIN with
an EXPRESSION and allow you to refer to the alias that
is created in the expression. ( SB requires a TABLE2
argument when doing a LEFT join. )

Tests added. All tests pass.

-Todd

left_join_expression.patch (7.84 KB)

This patch for DBIx::SB allows you to do a LEFT JOIN with
an EXPRESSION and allow you to refer to the alias that
is created in the expression. ( SB requires a TABLE2
argument when doing a LEFT join. )

Tests added. All tests pass.

It looks like you’ve added a new API. If so, you probably need to add
docs for it :wink:

(I’d take the cleanup refactoring on its own :wink:

This patch for DBIx::SB allows you to do a LEFT JOIN with
an EXPRESSION and allow you to refer to the alias that
is created in the expression. ( SB requires a TABLE2
argument when doing a LEFT join. )

Tests added. All tests pass.

It looks like you’ve added a new API. If so, you probably need to add
docs for it :wink:

(I’d take the cleanup refactoring on its own :wink:

Updated patch attached and submitted. :wink:

left_join_expression.patch (9.11 KB)

Ok. Now that I understand what it’s doing, the patch makes me twitch.
This is making an already complex API really intensely painful and
magical. Magic variable values just don’t belong there. A more
reasonable solution might be allowing you to call NewAlias ahead of
time, get the second Alias, pass it in as ALIAS2 and have the right
things happen to the query.On Aug 15, 2006, at 11:04 PM, Todd Chapman wrote:

On Tue, Aug 15, 2006 at 10:48:23PM -0400, Jesse Vincent wrote:

On Tue, Aug 15, 2006 at 10:37:50PM -0400, Todd Chapman wrote:

This patch for DBIx::SB allows you to do a LEFT JOIN with
an EXPRESSION and allow you to refer to the alias that
is created in the expression. ( SB requires a TABLE2
argument when doing a LEFT join. )

Tests added. All tests pass.

It looks like you’ve added a new API. If so, you probably need to add
docs for it :wink:

(I’d take the cleanup refactoring on its own :wink:

Updated patch attached and submitted. :wink:
<left_join_expression.patch>

PGP.sig (186 Bytes)

Ok. Now that I understand what it’s doing, the patch makes me twitch.
This is making an already complex API really intensely painful and
magical. Magic variable values just don’t belong there. A more
reasonable solution might be allowing you to call NewAlias ahead of
time, get the second Alias, pass it in as ALIAS2 and have the right
things happen to the query.

I agree that that would be a better solution. On the
solution/time curve I chose one that fit within my
time constraints while still providing some tests
and other clean-up. If it’s unacceptable I’ll try to
better when $available > $time.

Ok. Now that I understand what it’s doing, the patch makes me twitch.
This is making an already complex API really intensely painful and
magical. Magic variable values just don’t belong there. A more
reasonable solution might be allowing you to call NewAlias ahead of
time, get the second Alias, pass it in as ALIAS2 and have the right
things happen to the query.

I agree that that would be a better solution. On the
solution/time curve I chose one that fit within my
time constraints while still providing some tests
and other clean-up. If it’s unacceptable I’ll try to
better when $available > $time.

Ok. Sounds good. I’d happily take the code cleanups as their own patch
today.