Closed Bug 446122 Opened 16 years ago Closed 16 years ago

Search for proper names of add-ons often promotes add-ons with their substrings ahead in results

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: stephend, Assigned: laura)

References

()

Details

Attachments

(1 file)

Summary: Search for proper names of add-ons often promotes add-ons with their substrings ahead in results (summary probably is way off; tweak as needed.)

For background, see bug 378657 comment 16 and bug 378657 comment 17, especially.

The gist is that searches for proper-name add-ons, such as a search query of "tab preview" no longer (on preview, with the 3.4.6. codebase) yields Tab Preview (https://addons.mozilla.org/en-US/firefox/addon/6132) as its 1st hit.  Instead, Ctrl Tab Preview (https://addons.mozilla.org/en-US/firefox/addon/2134) shows up 1st.  A search for "Diggler" also no longer yields it 1st on preview.

On IRC, Fred notes, "we might need to factor this in with the default search sort order", so he suggested I mark as depends on bug 291413.  Also setting TM to 3.4.6 so we don't leave it behind.

Here's hoping I got this right...
Yeah, essentially, *exact* name hits don't always show up before *fuzzy/substring* name hits. My comments 16 and 17 stephend linked to in comment 0 explain the current sort order in more detail and suggest possible ways to fix this bug here as well.

Marking for TM 3.4.7 as this depends on sort order investigation done by basil as part of bug 291413, and it missed the 3.4.6 code freeze.
Target Milestone: 3.4.6 → 3.4.7
Assignee: nobody → laura
Target Milestone: 3.4.7 → 3.5.1
I'm going to remove the dependency on bug 291413 for this since that bug was about ordering of add-ons by rating not necessarily the search algo.

The algo described by Fred in bug 37657 comment 17 is fine.

Any additional work we do with search engines is going to require a fundamental change (as in replacement of MySQL index) and so we'll leave that for another bug/release.
No longer depends on: 291413
(In reply to comment #2)
> The algo described by Fred in bug 37657 comment 17 is fine.

I think you forgot a digit in the bug number.
Ugh, OK. Let me fix that. The algo described by Fred in bug 378657 comment 17 is fine. :-)
Priority: -- → P2
Laura: In order to implement this results order, I would do (pseudocode, oh yeah):

SELECT * FROM addons WHERE (name, description...) MATCHES (search query) ORDER BY (LOWERCASE(name) = 'exact query') DESC, (status = public) DESC, (name LIKE '%fuzzy%') DESC, fulltext_relevance DESC;

That, in combination with removing stop words should lead to very decent and quite intuitive results: exact name matches at the top, then public before sandboxed, after that fuzzy matches, then everything else.
Depends on: 447933
The full text index is fixed. If we implement the sort order now as outlined here, our search should perform even better.
Laura, any update on this bug?
Comment on attachment 343038 [details] [diff] [review]
Order exact name hits (well case insensitively anyway) first.

Works well for me: For example, Diggler, in spite of being experimental in my dev data, shows up first, as it is an exact name match.
Attachment #343038 - Flags: review?(fwenzel) → review+
Committed in r19057, thanks wenzel (for the idea and the review).
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: push-needed
Resolution: --- → FIXED
Verified FIXED; I ran my Selenium search suite, as well as manually tested, and this works beautifully.

(In fact, it's downright sexy now!)
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: