173689 - Default comments search box type to "contains string"

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect)

Description

[Gervase Markham [:gerv]]

Currently, the comment search, URL search and whiteboard search default to
"contains all of the words/strings". This leads to queries like this:

  3832327   bugs   localhost   shadow_bugs   Query     205    Copying to tmp
table   SELECT DISTINCT bugs.bug_id, bugs.groupset, bugs.bug_severity,
bugs.priority, bugs.rep_platform, map_assigned_to.login_name, bugs.bug_status,
bugs.resolution, bugs.short_desc FROM bugs, profiles map_assigned_to, profiles
map_reporter LEFT JOIN profiles map_qa_contact ON bugs.qa_contact =
map_qa_contact.userid, longdescs longdescs_ WHERE ((bugs.groupset & 0) =
bugs.groupset ) AND bugs.assigned_to = map_assigned_to.userid AND bugs.reporter
= map_reporter.userid AND longdescs_.bug_id = bugs.bug_id AND (bugs.product =
'Browser') AND (INSTR(LOWER(longdescs_.thetext), '"cannot') AND
INSTR(LOWER(longdescs_.thetext), 'be') AND INSTR(LOWER(longdescs_.thetext),
'found"') AND INSTR(LOWER(longdescs_.thetext), 'dialog')) ORDER BY bugs.bug_id   

He meant to search for bugs with the string "cannot be found dialog", but ended
up doing the very expensive search for bugs with "cannot", "be", "found" and
"dialog" all in the same comment, anywhere. I can see why he might have thought
that he had selected the correct option - "contains all of the words/strings"
could be assumed to mean "contains this entire string", if you weren't familiar
with the language.

This suggestion continues the trend of setting default values to less expensive
searches, so if people do the wrong thing, it doesn't cost too much of
Bugzilla's resources.

I think this change would be a reasonable default, rather than a b.m.o.-specific
customisation.

Gerv

Comment 1

[Gervase Markham [:gerv]]

An analysis of 17 killed queries showed this problem in 3 of them.

Gerv

Comment 2

[Andreas Franke (gone)]

Just some remarks:

- I assume the main case where the current option uses lots of resources is
search in comments/descriptions, not so much summary, url, and status
whiteboard. (The amout of text in comments is much larger than the rest.)

- The default search options of non-b.m.o bugzilla installations may be ok
as-is, depending on the size of the database and the power of the servers. For
the small and powerful installations you are trading performance with usability.
If you're planning more than just a single small change, then it should be made
easy for an admin to change it back to the defaults that are more usable and
that the users have learned already.

Comment 3

[Gervase Markham [:gerv]]

> - I assume the main case where the current option uses lots of resources is
> search in comments/descriptions, 

That's probably right, yes.

> For the small and powerful installations you are trading performance with
> usability.

Ah, but are you? My assertion is that "contains string" is most often what
people mean - at least on the comments search, and probably on URL too. You are
perhaps right in asserting that they probably mean "contains all words" more
often on summary and status whiteboard. (I had no plans to change summary anyway.)

> If you're planning more than just a single small change, then it should be 
> made easy for an admin to change it back to the defaults that are more usable 
> and that the users have learned already.

It's a simple change to the default query string Param.

Gerv

Comment 4

[Andreas Franke (gone)]

> It's a simple change to the default query string Param.

You're right, this one change alone is a simple change, but if you combine it
with the "exact email search" and other small changes, then it may be handy to
have a global switch to change all of them back to the more powerful, but more
resource intensive default settings. But I don't have a strong opinion on this;
I'm using quicksearch for >90% of my queries anyway.

> My assertion is that "contains string" is most often what people mean

Well, we probably do not have enough data to really decide this. For URL fields,
"contains string" is not very useful if the user has entered several words
(because URLs usually do not contain whitespace), so I think it makes sense to
keep the current default there. Wrt comments, it is not clear to me from your
example ("cannot be found dialog") that in this case the user really meant to
search for the string, but you are the native speaker, so I trust you on that.
Maybe it is possible to gather a few more examples?

Anyway, if this is just about changing the default option for comments search,
then this change certainly makes sense on b.m.o, and I don't have a problem with
changing this for all of bugzilla, since for most queries this field is not used
 anyway, and in the few cases where you need the other option, it's easy enough
to change it back.

Comment 5

[Gervase Markham [:gerv]]

> > My assertion is that "contains string" is most often what people mean
> 
> Well, we probably do not have enough data to really decide this. 

I get mail when mysqld-watcher kills threads for taking too long; and this
mistake is a very common one. 3 / 17, the figure I gave earlier, probably
understates it a bit.

Gerv

Comment 6

[Oleg Rekutin]

Note how the original query was:

   "cannot be found" dialog

Clearly he was relying on behavior where words entered in quotes are 
considered phrases (complete substrings), and words entered without quotes are 
standalone keywords. (many web searches, such as Google, work like this)

If Bugzilla recognized the quoted text as a phrase, the search would have been 
for two terms: 'cannot be found' and 'dialog'.

He probably did not want to select "contains this entire string" because the 
string that he was looking for was 'cannot be found', with 'dialog' being an 
additional keyword; that is, he did not want to look for string "cannot be 
found dialog".

Doing a search like what he intended (a phrase and a keyword) requires going 
thru the intimidating "Advanced Querying Using Boolean Charts" section: one of 
the parts of the query goes in the "Comments" section above, and the other 
part goes into the boolean section.

I think that Bugzilla could use smarter behavior here. If you could add 
another search mode that would do Google-like searches where double-quoted 
keywords are treated as a phrase and the rest of the keywords are required, 
then I think that would be appreciated even by the experienced Bugzilla users.

Also, consider having a list of ignored words, such as "be" and "the", so that 
Bugzilla doesn't search for them.

Comment 7

[Gervase Markham [:gerv]]

This has now been done on b.m.o. for comments search only, which is the one
causing the major problem.

Gerv

Comment 8

[Gervase Markham [:gerv]]

Unlike email addresses, I think this change (for comments search only) should be
in default Bugzilla, so I'm leaving this open.

Gerv

Comment 9

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Update default query.

Gerv

Comment 10

[Joel Peshkin]

Does bug 127200 make the underlying problem go away?  I suspect that it will.

Comment 11

[Dave Miller [:justdave]]

Comment on attachment 104423 [details] [diff] [review]
Patch v.1

makes sense to me.
r= justdave
a= justdave

Note this is only changing a DEFAULT parameter, and this will have no effect on
existing installations.  New installations can feel free to change it if they
don't like it, since it's a param.

Comment 12

[Gervase Markham [:gerv]]

Fixed.

Checking in defparams.pl;
/cvsroot/mozilla/webtools/bugzilla/defparams.pl,v  <--  defparams.pl
new revision: 1.96; previous revision: 1.95
done

Gerv