Full text search only understands whitespace as a word seperator

It doesn't find "Bug #29776 in control-center (Ubuntu): "/dev/pmu permissions wrong"" neither

In the long term this is a duplicate of bug 2795, though this particular example could be made to work by declaring "/" to be a word separator.

We can't fix bug 2795 in the short term without introducing scalability problems.

mpt - should I go ahead and make '/' a word seperator? Any other punctuation? I don't think "-", "." or "'" should be. @could be argued either way. &, | and ! are boolean operators.

Yes, as the MaloneSearch spec is now, a bug mentioning /dev/pmu should be returned in a search for "pmu", and in a search for "dev pmu". Is that reasonable?

Having '/' as a word separator sounds entirely reasonable, sane and consistent with other applications. Any reason not to do this?

What are the existing word separators?

The existing word seperators were just whitespace.

The first half of this has been implemented, based on directions set forward in the https://launchpad.net/products/malone/+spec/search specification. Queries from users are now being split into components the way we want and sent to the text searching engine. We still need to update the code that builds these indexes so that these updated searches actually match things though, as '/dev/pmu' is still stored as just '/dev/pmu' in the indexes rather than 'dev pmu devpmu'.

On 12-Feb-06, at 8:19 PM, Stuart Bishop wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/29227
>
> Changed in: Malone (upstream)
> Status: Confirmed => In Progress

This doesn't appear to be working yet; any news on this Stuart?

Cheers,

--
Brad Bollenbach

I haven't looked at this since my comment on Feb 13th.

The query should really be https://launchpad.net/distros/ubuntu/+bugs?field.searchtext=pmu&orderby=-importance&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Needs+Info&field.status%3Alist=Rejected&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.status%3Alist=Fix+Released&assignee_option=any&field.assignee=&field.owner=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_no_package.used=

Note that it does return bug 28855, but still fails to find bug 29776.

There is another problem when searching for words with a dot in them:

Searching for "menu.lst" finds bug 61108 but not bug 78901.
Both of them have the word menu.lst in theirs subject and description.

This has gone unnoticed for too long, going Critical to get it on the bug report report.

It isn't a critical bug, and not one suitable to a quick fix. It is most suitable for waiting until we are running PostgreSQL 8.2 which will help a lot with our outstanding searching issues.

On Tue, Feb 12, 2008 at 06:57:30PM -0000, Francis J. Lacoste wrote:
> ** Summary changed:
>
> - Searching for "pmu" doesn't find "/dev/pmu"
> + Full text search doesn't support substring match

Why couldn't we change the word separators, so that /dev/pmu gets treated
as two words, 'dev' and 'pmu'?

I've just filed another duplicate bug. Three years and counting to add sane word separators? I recommend replacing the search function with google site search in the meantime to at least get functioning search ;-)

If there is still some reason why you can't change the indexer's list of word separators yet, can you not at least temporarily modify the word separators used to analyze the query, so that a query for "/dev/pmu" will find bugs containing " /dev/pmu " (or in my case a query for "mantis-275" will find a bug containing the string " mantis-275 "). Currently search is totally broken and almost useless since even an exact text match of a white-space delimited word containing hyphens, dots or slashes doesn't find them at all.

Unassigning to reflect reality ;)