[Dbix-class] SQL::Abstract - boolean test support - should this
merge?
Peter Rabbitson
rabbit+dbic at rabbit.us
Thu Aug 20 15:24:08 GMT 2009
This is just to record my vote, which I shared with Nigel already.
Nigel Metheringham wrote:
> Boolean tests using SQLA (and hence DBIC) have always been a bit of a
> pain - you can do a test for a true value using the hackish
> { boolcolumn => \'' }
>
> which produces
> WHERE boolcolumn
>
> but there has been no reasonable alternative that would allow you to
> produce
> WHERE NOT boolcolumn
>
>
> A few months back, I finally got around to building better support for
> boolean tests in SQL::Abstract - you can see the branch at
>
> http://dev.catalyst.perl.org/svnweb/bast/browse/SQL-Abstract/1.x/branches/bool_operator/
>
>
> This implements the following syntax:-
> { -bool => boolcolumn }
> WHERE boolcolumn
>
> { -not_bool => boolcolumn }
> WHERE NOT boolcolumn
>
> { -and => [-bool => 'foo', -bool => 'bar'] }
> WHERE foo AND bar
>
> { -bool => \'function(x)' }
> WHERE function(x)
>
> This is slightly back to front compared to some other syntax, but
> allows other syntax extensions - for example NOT of a subselect etc.
>
> A side effect of this work is a significant re-factor of the SQLA code
> handling unary (or possibly a better name would be prefix) operators,
> which allows for subsequent expansion of those operators (currently the
> operators are -and -or -nest).
>
> So the big decision now is should this work be merged into the SQLA
> mainline. That at least partly depends on whether ash, as master of
> SQLA-v2 loves or hates it (no point adding syntax that he will prune).
>
> If the -bool/-not_bool part is not merged, should the refactor be taken
> in anyhow?
Probably not, the -and/-or machine is stable (albeit weird) the way it is, and -nest
may get a facelift before sqla2.
> There is an alternative solution to the *basic* boolean SQL test, which
> is to add it as a normal binary operation - which could be done like
> this:-
>
> my $sqla = SQL::Abstract->new(
> special_ops => [
> {
> regex => qr/bool/,
> handler => sub {
> my ( $self, $field, $op, $arg ) = @_;
> return ( $arg ? $field : "NOT $field" );
> },
> },
> ]
> );
>
> and leads to syntax like this:-
> { foo => {-bool, 1}, bar => {-bool, 0}}
> WHERE foo AND NOT bar
>
> This will have some issues (subselects and parameterised functions
> etc), although literal functions should work.
This will _only_ work for column values, as you can not have references
as hash keys (thus literal functions are off the table).
> It is quite possible to add both forms of syntax (although this may
> confuse the hell out of users unless we change the naming of one of
> them)
I wouldn't do that, either one or the other.
> So comments and votes (but this ain't a democracy) are welcome on the
> best way to take this forward...
>
My vote is for what's in the branch.
More information about the DBIx-Class
mailing list