Skip Menu |

This queue is for tickets about the SQL-Abstract CPAN distribution.

Report information
The Basics
Id: 56062
Status: resolved
Priority: 0/
Queue: SQL-Abstract

People
Owner: Nobody in particular
Requestors:
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.64



I want to use GLOB and REGEXP with SQL::Abstract, and the syntax of the WHERE clause has changed between versions 1.60 and 1.63. (SQLite is the database.) An error msg is printed: "wrong number of arguments to function GLOB() ... " ). In Version 1.60, if the WHERE clause used either LIKE or GLOB, e.g. if $where{somecol} = { 'glob' => 'string' }, then SQL::Abstract would print: ver1.60: WHERE ( somecol LIKE ? ) or ver1.60: WHERE ( somecol GLOB ? ) But in Version 1.63 I get different syntax, and of course, an error msg. The generated LIKE statement is the same, but for GLOB (or REGEXP) it's changed: ver1.63: WHERE ( somecol LIKE ? ) ver1.63: WHERE ( somecol = GLOB( ? ) ) So this may not be a bug, but how do I get around it?
On Mon Mar 29 12:25:54 2010, jdub wrote: Show quoted text
> I want to use GLOB and REGEXP with SQL::Abstract, and the syntax > of the WHERE clause has changed between versions 1.60 and 1.63. > (SQLite is the database.) An error msg is printed: > "wrong number of arguments to function GLOB() ... " ). > > In Version 1.60, if the WHERE clause used either LIKE or GLOB, e.g. if > $where{somecol} = { 'glob' => 'string' }, > then SQL::Abstract would print: > > ver1.60: WHERE ( somecol LIKE ? ) or > ver1.60: WHERE ( somecol GLOB ? ) > > > But in Version 1.63 I get different syntax, and of course, an error msg. > The generated LIKE statement is the same, but for GLOB (or REGEXP) it's > changed: > > ver1.63: WHERE ( somecol LIKE ? ) > ver1.63: WHERE ( somecol = GLOB( ? ) ) > > > So this may not be a bug, but how do I get around it?
Arguably it is a pretty incompatible bug which I should fix unless proven impossible. Please submit a test patch to t/02generate.t, showing the problem in the least code possible (do not overcomplicate the query). I will try to fix it within this week. As a workaround you can register a unary-op for the function in question - then the generated sql is entirely in your control: http://search.cpan.org/~ribasushi/SQL-Abstract-1.63/lib/SQL/Abstract.pm#UNARY_OPERATORS Cheers
Subject: test patch attached
From: jdub
OK, thanks for the swift reply. I've attached a test file 02generate.t. If it's too much trouble (or impossible), don't bother. For me it's going to be way easier to simply not upgrade; I really only wanted to use the promising new DBIx::Class::Helper::ResultSet::SetOperations. All my existing catalyst code has lots and lots of: ->search({ REGEXP => ... and ->search({ GLOB => '*str*' ... which I can't easily change. Thanks for the link to the unary-op, but I've got no idea what the doc is trying to say. I don't know how to make my own GLOB or REGEXP ops, and really wouldn't know how to get them into the catalyst app. I guess I'm surprised that no one else uses GLOB, but I'm not surprised that I've been doing it wrong all this time. Thanks for your time, -j
Subject: 02generate.t
#!/usr/bin/perl use strict; use warnings; use Test::More; use Test::Exception; use SQL::Abstract::Test import => ['is_same_sql_bind']; use Data::Dumper; use SQL::Abstract; my $not_stringifiable = bless {}, 'SQLA::NotStringifiable'; my @handle_tests = ( { where => { foo => {'GLOB' => '*str*'}, }, stmt => " WHERE foo GLOB ? ", bind => [ '*str*' ], }, { where => { foo => {'REGEXP' => 'bar|baz'}, }, stmt => " WHERE foo REGEXP ? ", bind => [ 'bar|baz' ], }, ); plan tests => ( @handle_tests * 2 ) + 1; for my $case (@handle_tests) { local $Data::Dumper::Terse = 1; my $sql = SQL::Abstract->new; my($stmt, @bind); lives_ok (sub { ($stmt, @bind) = $sql->where($case->{where}, $case->{order}); is_same_sql_bind($stmt, \@bind, $case->{stmt}, $case->{bind}) || diag "Search term:\n" . Dumper $case->{where}; }); } dies_ok { my $sql = SQL::Abstract->new; $sql->where({ foo => { '>=' => [] }},); };
Please try current trunk [1]. Issue should be fixed for good. I made a bold stupid assumption, and the lack of tests didn't prove me wrong immediately. Apologies. [1] http://dev.catalyst.perl.org/repos/bast/SQL-Abstract/1.x/trunk/
Subject: Tried current trunk--success!
From: jdub
On Sat Apr 03 20:21:06 2010, RIBASUSHI wrote: Show quoted text
> Please try current trunk [1]. Issue should be fixed for good. I made a > bold stupid assumption, and the lack of tests didn't prove me wrong > immediately. Apologies. > > [1] http://dev.catalyst.perl.org/repos/bast/SQL-Abstract/1.x/trunk/
Tremendous thanks! The new trunk version gives me same results as before (v1.61).