76498 - QuickSearch: support comparison operators other than substring

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement, P2)

Description

[Andreas Franke (gone)]

Currently the generic notation for a word is field1,...,fieldN:value1,...,valueM
and a bug matches iff one of the values occurs as a _substring_ in one of the
fields. This should be generalized to allow other comparison operators like
"regexp", "exact", and probably more.

Question 1: Should there be a possibility to specify the comparison operator for
each value, or is it sufficient to have the same comparison operator for all
values. You can always use multiple words with an OR (or "|") between them to
achieve different operators for different values, but it may still be more
natural in some cases to indicate the comparison operator together with the
value, e.g. it would be easy to implement that everything between /.../ is
treated as a regexp. But there are other solutions.

Then the main challenge is to find a good syntax for each of these operators.
A single ":" is used for substring. I can think of two possible approaches:
I.) use other characters _instead_ of the colon
	e.g. foo,bar=1,2,3 could be used for exact matching
II.) use more characters _in addition to_ the colon
	e.g. foo,bar:=1,2,3 could be used for exact matching

"::" is very easy to type, so it should be used for a frequently used operator.

Comment 1

[Dave Miller [:justdave]]

.

Comment 2

[zxzx]

Attachment: buy cheap paxil

(spam deleted)

Comment 3

[Dave Miller [:justdave]]

The content of attachment 263723 [details] has been deleted by
    Dave Miller (work related) <[e-mail]>
who provided the following reason:

Attachment was spam.

The token used to delete this attachment was generated at 2007-05-04 08:36:50 PDT.

Comment 4

[Jesse Ruderman]

For numeric fields such as "votes", I'd like < and > operators.

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I also would like <,> for days_elapsed

Comment 6

[Daniel Veditz [:dveditz]]

I'm not convinced days_elapsed does anything sane in quicksearch in any case

I get 180 bugs (mostly very old) for
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3AXBL

For one day elapsed (of which there's only one) I get 70 bugs (mostly very old):
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3AXBL%20days_elapsed%3A1

As I increment the days_elapsed I get smaller and larger numbers that seem to have nothing to do with the changed date.

Comment 7

[:glob ✱]

Attachment: 76498_1.patch

getting quicksearch to support this is relatively simple, the hard bit will be deciding on a syntax which causes the least amount of breaking of existing queries.

here's a patch which adds new symbols which can be used instead of :

eg. creation_ts<-2w does "creation_ts" "lessthan" "-2w"

the full map is:
 ':'  => 'substring',
 '='  => 'equals',
 '!=' => 'notequals',
 '>=' => 'greaterthaneq',
 '<=' => 'lessthaneq',
 '>'  => 'greaterthan',
 '<'  => 'lessthan',

Comment 9

[Simon Green]

Comment on attachment 803068 [details] [diff] [review]
76498_1.patch

The patch is good (very good in fact), but you need to update the documentation with this functionality as well (template/en/default/pages/quicksearch.html.tmpl)

Comment 10

[:glob ✱]

Attachment: 76498_2.patch

Comment 11

[Simon Green]

Comment on attachment 8345700 [details] [diff] [review]
76498_2.patch

Review of attachment 8345700 [details] [diff] [review]:
-----------------------------------------------------------------

::: template/en/default/pages/quicksearch.html.tmpl
@@ +234,5 @@
> +        where the <kbd>summary</kbd> is not <kbd>foo</kbd>.
> +      </li>
> +      <li>
> +        <strong>&gt;</strong> (greaterthan):<br>
> +        <kbd><em>creation_ts>-2w</em></kbd> will search for [% terms.bugs %]

Replace > with &gt; Same with the documentation for >=

@@ +246,5 @@
> +        terms.bugs %] exactly two weeks old.
> +      </li>
> +      <li>
> +        <strong>&lt;</strong> (lessthan):<br>
> +        <kbd><em>creation_ts>-2w</em></kbd> will search for [% terms.bugs %]

Replace > with &lt; . Same with the documentation for <=

Comment 13

[Frédéric Buclin]

It looks like this patch is close to r+. glob: could you update it, please?

Comment 15

[:glob ✱]

Attachment: 76498_3.patch

Comment 16

[Frédéric Buclin]

Comment on attachment 8360238 [details] [diff] [review]
76498_3.patch

Please backport it to bmo asap! :) r=LpSolit

Comment 17

[Frédéric Buclin]

Comment on attachment 8360238 [details] [diff] [review]
76498_3.patch

>=== modified file 'Bugzilla/Search/Quicksearch.pm'
>-    my @field_values = _parse_line(':', 1, $or_operand);
>-    if (scalar @field_values == 2) {
>-        my @fields = _parse_line(',', 1, $field_values[0]);
>-        my @values = _parse_line(',', 1, $field_values[1]);
>+        my @field_values = parse_line($symbol, 1, $or_operand);
>+        next unless scalar @field_values == 2;
>+        my @fields = parse_line(',', 1, $field_values[0]);
>+        my @values = parse_line(',', 1, $field_values[1]);

Just to be sure: replacing _parse_line() by parse_line() is intentional, isn't it?

Comment 18

[Dave Miller [:justdave]]

This is way cool.  Make sure comment 17 is addressed, then commit at will.

Comment 19

[Frédéric Buclin]

We are releasing today and glob is not around, so I'm committing the patch myself.

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/Search/Quicksearch.pm
modified template/en/default/pages/quicksearch.html.tmpl
Committed revision 8895.

Comment 20

[Frédéric Buclin]

I had to fix bustage on Perl 5.10 and 5.12:

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/Search/Quicksearch.pm
Committed revision 8896.

Comment 21

[:glob ✱]

(In reply to Frédéric Buclin from comment #17)
> Just to be sure: replacing _parse_line() by parse_line() is intentional,
> isn't it?

no, it isn't intentional, and reverts the fix in bug 877545 when searching for multiple values.
fixed:

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/Search/Quicksearch.pm
Committed revision 8901.

Comment 23

[Frédéric Buclin]

Added to relnotes for 5.0rc1.