Bug #46881 for Search-QueryParser-SQL: INTs are being fuzzified

Fri Jun 12 05:20:57 2009 maz [...] mlx.net - Ticket created

Subject:	INTs are being fuzzified
Date:	Fri, 12 Jun 2009 17:20:14 +0800
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	John Maslanik <maz [...] mlx.net>

Adding the following to the _doctor_value sub is how I fixed it. my $value = $subQ->{value}; + if($self->{_parser}->{_is_int}->{ $subQ->{field} }) { + return $value; + } John Maslanik

Fri Jun 12 10:24:43 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Fri, 12 Jun 2009 09:24:23 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

John Maslanik via RT wrote on 6/12/09 4:21 AM: Show quoted text

> Fri Jun 12 05:20:57 2009: Request 46881 was acted upon. > Transaction: Ticket created by maz@mlx.net > Queue: Search-QueryParser-SQL > Subject: INTs are being fuzzified > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: maz@mlx.net > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > > Adding the following to the _doctor_value sub is how I fixed it. > > my $value = $subQ->{value}; > > + if($self->{_parser}->{_is_int}->{ $subQ->{field} }) { > + return $value; > + } > > John Maslanik > >

Thanks. It was a little more complicated than that but definitely was on my todo list. I just needed the push to get it done. Please try svn trunk from here and confirm that it works for you and I'll release a new version to CPAN. https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk/ -- Peter Karman . http://peknet.com/ . peter@peknet.com

Fri Jun 12 10:24:44 2009 The RT System itself - Status changed from 'new' to 'open'

Mon Jun 15 08:52:28 2009 maz [...] mlx.net - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Mon, 15 Jun 2009 20:52:03 +0800
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	John Maslanik <maz [...] mlx.net>

Peter, Thank you for the quick response. I apologize for my delay. I would be more than happy to test your changes, but I have hacked another feature into my copy. I needed to have the ability to have aliases for field names. For example, I use DBIx::Class and have a query that queries Inventory, InventoryXArtists and Artists tables. If I had inventory_id in my field list, the query would fail because inventory_id is in both inventory and inventoryxartist tables. So what I did was add an extra parameter to the constructor called "aliases" that consists of a hash of aliases. (i.e. { 'inventory_id' => 'me.inventory_id', 'name' => 'artist.name' }). I then added code that in your column loop after the "TODO better operator selection" comment that checks aliases and renames columns if they exists. I also want to add some type of call back functionality that handles things such as the following situation. The inventory table can be queried looking for entries added in the last x days. So when someone enters recent:30, the query needs to end up being, 'to_days(now()) - to_days(me.date_created) <= $recent'. Now that I'm thinking about it, the aliases feature handles everything but changing the operator. I would love to change columns to be something like: $columns = { 'column_name' => { 'type' => 'int|char|etc", 'alias' => 'name to use for sql query', 'op' => 'name of op to force', 'callback' => 'call to function that takes $column, $op, and $value and returns what's pushed on to buf' } } unfortunately I think that would break backwards compatibility. Maybe I could put something that loops through the columns hash, checking if the members are a string or a hash and convert them if needed. What are your thoughts? I'm more than willing to do the code, all you have to do is review it and submit it. Thanks, John Maslanik On Jun 12, 2009, at 10:24 PM, peter@peknet.com via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > John Maslanik via RT wrote on 6/12/09 4:21 AM:

>> Fri Jun 12 05:20:57 2009: Request 46881 was acted upon. >> Transaction: Ticket created by maz@mlx.net >> Queue: Search-QueryParser-SQL >> Subject: INTs are being fuzzified >> Broken in: (no value) >> Severity: (no value) >> Owner: Nobody >> Requestors: maz@mlx.net >> Status: new >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > >> >> >> Adding the following to the _doctor_value sub is how I fixed it. >> >> my $value = $subQ->{value}; >> >> + if($self->{_parser}->{_is_int}->{ $subQ->{field} }) { >> + return $value; >> + } >> >> John Maslanik >> >>

> > Thanks. It was a little more complicated than that but definitely > was on my todo > list. I just needed the push to get it done. > > Please try svn trunk from here and confirm that it works for you and > I'll > release a new version to CPAN. > > https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk/ > > -- > Peter Karman . http://peknet.com/ . peter@peknet.com >

Mon Jun 15 21:19:38 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Mon, 15 Jun 2009 20:19:16 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

John Maslanik via RT wrote on 6/15/09 7:52 AM: Show quoted text

> Queue: Search-QueryParser-SQL > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > Peter, > > Thank you for the quick response. I apologize for my delay. I would > be more than happy to test your changes, but I have hacked another > feature into my copy. I needed to have the ability to have aliases > for field names. For example, I use DBIx::Class and have a query that > queries Inventory, InventoryXArtists and Artists tables. If I had > inventory_id in my field list, the query would fail because > inventory_id is in both inventory and inventoryxartist tables. So > what I did was add an extra parameter to the constructor called > "aliases" that consists of a hash of aliases. (i.e. { 'inventory_id' > => 'me.inventory_id', 'name' => 'artist.name' }). I then added code > that in your column loop after the "TODO better operator selection" > comment that checks aliases and renames columns if they exists. > > I also want to add some type of call back functionality that handles > things such as the following situation. > > The inventory table can be queried looking for entries added in the > last x days. So when someone enters recent:30, the query needs to end > up being, 'to_days(now()) - to_days(me.date_created) <= $recent'. Now > that I'm thinking about it, the aliases feature handles everything but > changing the operator. > > I would love to change columns to be something like: > > $columns = { > 'column_name' => { > 'type' => 'int|char|etc", > 'alias' => 'name to use for sql query', > 'op' => 'name of op to force', > 'callback' => 'call to function that takes $column, $op, and $value > and returns what's pushed on to buf' > } > } > > unfortunately I think that would break backwards compatibility. > > Maybe I could put something that loops through the columns hash, > checking if the members are a string or a hash and convert them if > needed. > > What are your thoughts? I'm more than willing to do the code, all you > have to do is review it and submit it. >

column aliases, etc., sound fine, as long as current tests pass. feel free to patch against svn trunk here: https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk/ be sure to include tests and docs for the new features. -- Peter Karman . http://peknet.com/ . peter@peknet.com gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9

Wed Jun 17 02:21:19 2009 maz [...] mlx.net - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Wed, 17 Jun 2009 14:20:50 +0800
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	John Maslanik <maz [...] mlx.net>

Peter, Attached or modified Query.pm and SQL.pm files. They are modified from the cvs link below. The following features and/or bug fixes are added. 1. Added "aliases" option to the constructor. If passed, column names will be transformed in accordance with the alias hash. 2. Added int_op option to the constructor. This sets what default operator to use for int fields. There was also a bug where the int operator was set to GT, this is not valid for mysql. 3. Made -keyword queries work. This consists of setting "NOT $like" when the $prefix is '-' and joining sub queries with "AND" instead of OR when the $prefix is '-', it also sets op to != for ints. 4. In the unwind_subQ function, $like had padding added twice when doing the int check. Let me know how it looks. Thanks, John Maslanik

Message body is not shown because sender requested not to inline it.

On Jun 16, 2009, at 9:19 AM, peter@peknet.com via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=46881 > > > John Maslanik via RT wrote on 6/15/09 7:52 AM:

>> Queue: Search-QueryParser-SQL >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > >> >> Peter, >> >> Thank you for the quick response. I apologize for my delay. I would >> be more than happy to test your changes, but I have hacked another >> feature into my copy. I needed to have the ability to have aliases >> for field names. For example, I use DBIx::Class and have a query >> that >> queries Inventory, InventoryXArtists and Artists tables. If I had >> inventory_id in my field list, the query would fail because >> inventory_id is in both inventory and inventoryxartist tables. So >> what I did was add an extra parameter to the constructor called >> "aliases" that consists of a hash of aliases. (i.e. >> { 'inventory_id' >> => 'me.inventory_id', 'name' => 'artist.name' }). I then added code >> that in your column loop after the "TODO better operator selection" >> comment that checks aliases and renames columns if they exists. >> >> I also want to add some type of call back functionality that handles >> things such as the following situation. >> >> The inventory table can be queried looking for entries added in the >> last x days. So when someone enters recent:30, the query needs to >> end >> up being, 'to_days(now()) - to_days(me.date_created) <= $recent'. >> Now >> that I'm thinking about it, the aliases feature handles everything >> but >> changing the operator. >> >> I would love to change columns to be something like: >> >> $columns = { >> 'column_name' => { >> 'type' => 'int|char|etc", >> 'alias' => 'name to use for sql query', >> 'op' => 'name of op to force', >> 'callback' => 'call to function that takes $column, $op, and $value >> and returns what's pushed on to buf' >> } >> } >> >> unfortunately I think that would break backwards compatibility. >> >> Maybe I could put something that loops through the columns hash, >> checking if the members are a string or a hash and convert them if >> needed. >> >> What are your thoughts? I'm more than willing to do the code, all >> you >> have to do is review it and submit it. >>

> > column aliases, etc., sound fine, as long as current tests pass. > > feel free to patch against svn trunk here: > > https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk/ > > be sure to include tests and docs for the new features. > > -- > Peter Karman . http://peknet.com/ . peter@peknet.com > gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9 >

Wed Jun 17 21:57:19 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Wed, 17 Jun 2009 20:56:59 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

John Maslanik via RT wrote on 6/17/09 1:21 AM: Show quoted text

> Queue: Search-QueryParser-SQL > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > Peter, > > Attached or modified Query.pm and SQL.pm files. They are modified > from the cvs link below. The following features and/or bug fixes are > added. > > 1. Added "aliases" option to the constructor. If passed, column > names will be transformed in accordance with the alias hash. > 2. Added int_op option to the constructor. This sets what default > operator to use for int fields. There was also a bug where the int > operator was set to GT, this is not valid for mysql. > 3. Made -keyword queries work. This consists of setting "NOT $like" > when the $prefix is '-' and joining sub queries with "AND" instead of > OR when the $prefix is '-', it also sets op to != for ints. > 4. In the unwind_subQ function, $like had padding added twice when > doing the int check. > > Let me know how it looks. >

John, Thanks for the patches. First, those look like decent changes, but it's hard to tell without tests. Show quoted text

>> be sure to include tests and docs for the new features.

I didn't see those. Second, those patches cause 4 existing tests to fail. Output below: t/00-load.t ....... 1/1 # Testing Search::QueryParser::SQL 0.008 t/00-load.t ....... ok t/01-parser.t ..... 1/30 # Failed test 'query8 fuzzy int with wildcard string' # at t/01-parser.t line 94. # got: 'bar<=1' # expected: 'bar>=1' # Failed test 'query8 fuzzy int no wildcard string' # at t/01-parser.t line 98. # got: 'bar<=1' # expected: 'bar>=1' # Looks like you failed 2 tests of 30. t/01-parser.t ..... Dubious, test returned 2 (wstat 512, 0x200) Failed 2/30 subtests t/02-dbi.t ........ 1/29 # Failed test 'parser4_query dbi->[0]' # at t/02-dbi.t line 91. # got: 'foo ILIKE ? AND bar<=? AND dt<=?' # expected: 'foo ILIKE ? AND bar>=? AND dt>=?' # Looks like you failed 1 test of 29. t/02-dbi.t ........ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/29 subtests t/03-orm.t ........ 1/23 # Failed test 'parser4_query string' # at t/03-orm.t line 183. # Structures begin differing at: # $got->[1][3]{ge} = Does not exist # $expected->[1][3]{ge} = '123' # Looks like you failed 1 test of 23. t/03-orm.t ........ Dubious, test returned 1 (wstat 256, 0x100) Failed 1/23 subtests pek -- Peter Karman . http://peknet.com/ . peter@peknet.com gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9

Tue Jun 23 02:02:43 2009 slagelwa [...] yahoo.com - Correspondence added

Thanks Peter for creating this module and John for your efforts to enhance it. I'm stuck with the same new features you need. I downloaded and tried your patches, and found that all of the tests worked. On Wed Jun 17 21:57:19 2009, peter@peknet.com wrote: Show quoted text

> John Maslanik via RT wrote on 6/17/09 1:21 AM:

> > Queue: Search-QueryParser-SQL > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > > > Peter, > > > > Attached or modified Query.pm and SQL.pm files. They are modified > > from the cvs link below. The following features and/or bug fixes are > > added. > > > > 1. Added "aliases" option to the constructor. If passed, column > > names will be transformed in accordance with the alias hash. > > 2. Added int_op option to the constructor. This sets what default > > operator to use for int fields. There was also a bug where the int > > operator was set to GT, this is not valid for mysql. > > 3. Made -keyword queries work. This consists of setting "NOT $like" > > when the $prefix is '-' and joining sub queries with "AND" instead of > > OR when the $prefix is '-', it also sets op to != for ints. > > 4. In the unwind_subQ function, $like had padding added twice when > > doing the int check. > > > > Let me know how it looks. > >

> > John, > > Thanks for the patches. > > First, those look like decent changes, but it's hard to tell without

tests. Show quoted text

>

> >> be sure to include tests and docs for the new features.

> > I didn't see those. > > Second, those patches cause 4 existing tests to fail. Output below: > > t/00-load.t ....... 1/1 # Testing Search::QueryParser::SQL 0.008 > t/00-load.t ....... ok > t/01-parser.t ..... 1/30 > # Failed test 'query8 fuzzy int with wildcard string' > # at t/01-parser.t line 94. > # got: 'bar<=1' > # expected: 'bar>=1' > > # Failed test 'query8 fuzzy int no wildcard string' > # at t/01-parser.t line 98. > # got: 'bar<=1' > # expected: 'bar>=1' > # Looks like you failed 2 tests of 30. > t/01-parser.t ..... Dubious, test returned 2 (wstat 512, 0x200) > Failed 2/30 subtests > t/02-dbi.t ........ 1/29 > # Failed test 'parser4_query dbi->[0]' > # at t/02-dbi.t line 91. > # got: 'foo ILIKE ? AND bar<=? AND dt<=?' > # expected: 'foo ILIKE ? AND bar>=? AND dt>=?' > # Looks like you failed 1 test of 29. > t/02-dbi.t ........ Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/29 subtests > t/03-orm.t ........ 1/23 > # Failed test 'parser4_query string' > # at t/03-orm.t line 183. > # Structures begin differing at: > # $got->[1][3]{ge} = Does not exist > # $expected->[1][3]{ge} = '123' > # Looks like you failed 1 test of 23. > t/03-orm.t ........ Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/23 subtests > > > pek

Thu Jun 25 23:21:08 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Thu, 25 Jun 2009 22:20:48 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

Joe Slagel via RT wrote on 6/23/09 1:02 AM: Show quoted text

> Queue: Search-QueryParser-SQL > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > Thanks Peter for creating this module and John for your efforts to > enhance it. I'm stuck with the same new features you need. I > downloaded and tried your patches, and found that all of the tests worked.

yes, John's patches will pass against the tests in the released CPAN version 0.007. But they do not pass the tests in svn trunk here: https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk -- Peter Karman . http://peknet.com/ . peter@peknet.com gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9

Thu Jun 25 23:25:46 2009 maz [...] mlx.net - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Fri, 26 Jun 2009 11:25:19 +0800
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	John Maslanik <maz [...] mlx.net>

They don't pass the svn trunk because of a difference in the defaulting of the int operators '<=' vs '>='. If you change the default to what the test expects, it will work. As soon as I find some spare time, I'll write tests for the other new features. John On Jun 26, 2009, at 11:21 AM, peter@peknet.com via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=46881 > > > Joe Slagel via RT wrote on 6/23/09 1:02 AM:

>> Queue: Search-QueryParser-SQL >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > >> >> Thanks Peter for creating this module and John for your efforts to >> enhance it. I'm stuck with the same new features you need. I >> downloaded and tried your patches, and found that all of the tests >> worked.

> > yes, John's patches will pass against the tests in the released CPAN > version > 0.007. But they do not pass the tests in svn trunk here: > > https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk > > > -- > Peter Karman . http://peknet.com/ . peter@peknet.com > gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9 >

Thu Jun 25 23:34:36 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Thu, 25 Jun 2009 22:34:17 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

John Maslanik via RT wrote on 6/25/09 10:25 PM: Show quoted text

> Queue: Search-QueryParser-SQL > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=46881 > > > They don't pass the svn trunk because of a difference in the > defaulting of the int operators '<=' vs '>='. If you change the > default to what the test expects, it will work. As soon as I find > some spare time, I'll write tests for the other new features. >

ah, ok. I see that change with the int operator. Which brings up a good point. My assumption was that a query like: 1* means: match 1 or 10 or 1nnnnnn i.e., >= 1 but your change means it will render as: <= 1 which doesn't seem right to me. I.e., match 1 or 0 or -6534. I guess the wildcard in a numerical context is open to interpretation. Same thing with dates. I assume that: 2009-* means: match any date in 2009 so should probably be expanded to: Show quoted text

>= 2009-01-01 AND <= 2009-12-31

So what should the behavior be? I'm not saying that >= is correct, but <= seems less correct. -- Peter Karman . http://peknet.com/ . peter@peknet.com gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9

Fri Jun 26 02:31:15 2009 maz [...] mlx.net - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Fri, 26 Jun 2009 14:30:46 +0800
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	John Maslanik <maz [...] mlx.net>

Peter, LOL. My assumptions were based on thing like year_issued and price, with a default sort of ascending. So if someone entered $100, the first in the list would be 100. I figured everyone would have a difference of opinion as to what the default int operator should be, which is why I added the 'int_op' option to the constructor. Could also depend on the application. I could imagine a status field rendered by a select box being '=' and not < or >. John On Jun 26, 2009, at 11:34 AM, peter@peknet.com via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > John Maslanik via RT wrote on 6/25/09 10:25 PM:

>> Queue: Search-QueryParser-SQL >> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=46881 > >> >> They don't pass the svn trunk because of a difference in the >> defaulting of the int operators '<=' vs '>='. If you change the >> default to what the test expects, it will work. As soon as I find >> some spare time, I'll write tests for the other new features. >>

> > ah, ok. I see that change with the int operator. Which brings up a > good point. > My assumption was that a query like: > > 1* > > means: > > match 1 or 10 or 1nnnnnn > > i.e., >= 1 > > but your change means it will render as: > > <= 1 > > which doesn't seem right to me. I.e., > > match 1 or 0 or -6534. > > I guess the wildcard in a numerical context is open to > interpretation. Same > thing with dates. I assume that: > > 2009-* > > means: > > match any date in 2009 > > so should probably be expanded to: >

>> = 2009-01-01 AND <= 2009-12-31

> > > So what should the behavior be? I'm not saying that >= is correct, > but <= seems > less correct. > > -- > Peter Karman . http://peknet.com/ . peter@peknet.com > gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9 >

Fri Jun 26 11:45:05 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Fri, 26 Jun 2009 10:44:38 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

John Maslanik via RT wrote: Show quoted text

> Queue: Search-QueryParser-SQL > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46881 > > > Peter, > > LOL. My assumptions were based on thing like year_issued and price, > with a default sort of ascending. So if someone entered $100, the > first in the list would be 100. I figured everyone would have a > difference of opinion as to what the default int operator should be, > which is why I added the 'int_op' option to the constructor. Could > also depend on the application. I could imagine a status field > rendered by a select box being '=' and not < or >. > >

Ah, ok. I see now where you're coming from. Seems like each column should have a optional hashref of config, including: fuzzy_op fuzzy_not_op type where if type is set and others are not, there are some sane defaults. I'll try and refactor that direction this weekend. -- Peter Karman . http://peknet.com/ . peter@peknet.com gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9

Sat Jun 27 16:17:01 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Sat, 27 Jun 2009 15:16:41 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

John Maslanik via RT wrote on 6/15/09 7:52 AM: Show quoted text

> I would love to change columns to be something like: > > $columns = { > 'column_name' => { > 'type' => 'int|char|etc", > 'alias' => 'name to use for sql query', > 'op' => 'name of op to force', > 'callback' => 'call to function that takes $column, $op, and $value > and returns what's pushed on to buf' > } > }

I just checked in an implementation very similar to this. Please try svn trunk and see if it works for you: https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk/ Trac changeset: https://trac.msi.umn.edu/trac/sw/changeset/539 If the new API works for you, I'll upload to CPAN as 0.008. Thanks. -- Peter Karman . http://peknet.com/ . peter@peknet.com gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9

Mon Jul 13 13:25:30 2009 peter [...] peknet.com - Correspondence added

Subject:	Re: [rt.cpan.org #46881] INTs are being fuzzified
Date:	Mon, 13 Jul 2009 12:24:54 -0500
To:	bug-Search-QueryParser-SQL [...] rt.cpan.org
From:	Peter Karman <peter [...] peknet.com>

peter@peknet.com via RT wrote on 06/27/2009 03:17 PM: Show quoted text

> Please try svn trunk and see if it works for you: > > https://svn.msi.umn.edu/sw/perl/Search-QueryParser-SQL/trunk/

Just tickling this rt ticket to see if you've had a chance to test svn. -- Peter Karman . http://peknet.com/ . peter@peknet.com gpg key: 37D2 DAA6 3A13 D415 4295 3A69 448F E556 374A 34D9

Wed Aug 19 00:03:18 2009 karman [...] cpan.org - Correspondence added

no response. uploaded 0.008 to pause just now to let the cpantesters smoke it.

Wed Aug 19 00:03:19 2009 karman [...] cpan.org - Status changed from 'open' to 'resolved'