Bug searching should default to case-insensitive substrings

[Matthew Paul Thomas]

When I search Malone bug reports for "duplicate", I get 14 results. I would expect searching for "dup" to cast the net wider -- catching bugs that refer to "dup", "dups", "dupe", "dupes", "duping", "duplicate", "duplicates", and "duplicating". However, it returns only 3 results.

I suggest Malone default to searching for case-insensitive substrings, like Bugzilla does.

[Stuart Bishop (stub)]

Google doesn't work like this - why should searching for 'dup' match 'duplicate'?

At the moment we don't have the technology to do efficient substring searching except in limited circumstances, and developing it will be a major project both in terms of both research (data structures to allow this) and implementation (developing custom indexes for PostgreSQL).

Nobody should commit code just doing 'WHERE lower(description) LIKE '%foo%' because this will break Launchpad.

[Brad Bollenbach (bradb)]

It's possible that "dup" -> "duplicate" is a bit overambitious, but maybe not.

There's something to be said for making our search results less literal, particularly for those who have a harder time typing, or are just plain too lazy to type the entire word.

I would be surprised, for example, if "firef" didn't pick up "firefox".

[Matthew Paul Thomas (mpt)]

Google doesn't need to do this because even if the page you're looking for doesn't use the word "duplicating", there probably will be several other pages linking to it with text that does. (For example, the Demoroniser page is the #1 Google result for "demoronizer", despite that spelling occurring nowhere in the page.)

Malone doesn't, and will never, have that kind of massive synonym generation, so we need to use bruter force in generating the results people are looking for. That includes searching for substrings by default, just like Bugzilla and Trac do. (Today, for example, I unsuccessfully searched Malone for "subscri" to find bugs about subscribing/subscriptions.)