378657 - exact name hits should sort first

Status: VERIFIED FIXED

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

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Right now we sort all name hits equally, which gives undesirable ordering on searches like the one in the URL field above, for "forecastfox".  Exact matches on the title should probably get the #1 spot, not sure how best to do that (sql or app logic).

Comment 1

[Laura Thomson :laura]

We can do this without the FTS implementation referenced in bug 400986.

We can run another query that uses = instead of LIKE on the title.

(Posting this comment over there as well.)

Comment 2

[Laura Thomson :laura]

Attachment: Exact name hit should come first regardless of other search orders

Do these semantics work when advanced search lets you choose the search order?  Maybe we need a UI change?

Comment 3

[Fred Wenzel [:wenzel]]

Comment on attachment 323404 [details] [diff] [review]
Exact name hit should come first regardless of other search orders

No, I don't see why we need a UI change. It's not surprising to have an exact name match show up at the top.

Btw. if I were you I'd "break;" when you find a match, so that on average you only need to touch n/2 results and not all n results.

This is not the most well-performing thing either, but it will go away anyway once we use a different type of search, right?

Comment 4

[Laura Thomson :laura]

Added break; committed in r14469.  (I could have sworn I did that, thanks for the heads up.)

Yeah, it's not great performance although better than another series of monster left joins which is why I did it here and not in the DB.  As you say, it should be obsoleted by full text search.

Comment 5

[Chris Pollett]

Comment on attachment 323404 [details] [diff] [review]
Exact name hit should come first regardless of other search orders

wenzel's so fast, but here's my r+

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using https://preview.addons.mozilla.org/en-US/firefox/search?q=forecastfox&cat=all.

Additionally, a search for "Diggler" (a sandboxed add-on) on preview [https://preview.addons.mozilla.org/en-US/firefox/search?q=diggler&cat=all&as=true&appid=1&lver=0.3&hver=3.0&atype=1&pid=1&lup=&pp=20&sort=name] yields the exact name hit "Diggler" first; that same search on production [https://addons.mozilla.org/en-US/firefox/search?q=diggler&cat=all] yields it fourth.

Comment 7

[Mycroft Project (CC)]

This doesn't look right tom me:
https://preview.addons.mozilla.org/en-US/firefox/search?q=ie+tab&cat=all

compare:
https://preview.addons.mozilla.org/en-US/firefox/search?q=internet+explorer+tab&cat=all

Comment 9

[Mycroft Project (CC)]

actually the search in comment #6 has the exact match half way down the page as well so perhaps this has regressed?

Comment 11

[Anton P.]

I confirm this bug: a search for "Open link in..." (with or without quotes) under "all add-ons" only returns the extension whose name is "Open link in..." as the 35th result.  (The results list is not alphabetical.)

Comment 12

[Laura Thomson :laura]

This will be solved by bug 439227 and associated work.

Comment 13

[Fred Wenzel [:wenzel]]

Attachment: Sort name hits first, in SQL

To sort name hits first, even if the relevance ranking would put them on the second page, we need to do it in SQL. This patch backs out attachment 323404 [details] [diff] [review] and adds an "order by" clause to do the trick.

Comment 14

[Fred Wenzel [:wenzel]]

Thanks: r17135.

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

* https://preview.addons.mozilla.org/en-US/firefox/search?q=open+link+in&cat=all -- first hit is "Open Link In"
* https://preview.addons.mozilla.org/en-US/firefox/search?q=ie+tab&cat=all -- first hit is "IE Tab"
* https://preview.addons.mozilla.org/en-US/firefox/search?q=internet+explorer+tab&cat=all -- first hit is also "IE Tab"
* https://preview.addons.mozilla.org/en-US/firefox/search?q=close+all+tabs&cat=all -- first hit is "Close All Tabs" (oddly enough, on production, that add-on can't be found with that phrase, yet a search for just "Close All" finds it, albeit down the page a ways

I did find a regression, though, I think, and that is that substring searches such as "tab preview" on preview will now yield the "Tab Preview" add-on 2nd to "Ctrl Tab Preview", where that specific use-case lists "Tab Preview" 1st on production and "Ctrl Tab Preview" 2nd.  Probably need a spin-off bug for that?

Comment 16

[Fred Wenzel [:wenzel]]

(In reply to comment #15)
> I did find a regression, though, I think, and that is that substring searches
> such as "tab preview" on preview will now yield the "Tab Preview" add-on 2nd to
> "Ctrl Tab Preview", where that specific use-case lists "Tab Preview" 1st on
> production and "Ctrl Tab Preview" 2nd.  Probably need a spin-off bug for that?

Well, we do need to get our requirements straight. (Same with "Diggler" that you mentioned on IRC): The first criteria is public vs. sandbox (which puts diggler behind *all* matching public add-ons). The second criteria is a name match like "*diggler*" (meaning, all add-ons whose names that match this are returned before all that don't). The third one now is the relevance count assigned by MySQL's fulltext search.

As both "Tab Preview" and "Ctrl Tab Preview" are public and match "*tab preview*", their order is distinguished by MySQL's relevance measure, and apparently, MySQL found the latter more appropriate for your search term than the former.

If we want to change this, I could use a more stricter name match, like "^tab preview.*" (meaning, strings starting with this exact term only), but we need to be aware that this rule won't automatically put "MyFacebookAddon" (I made that up) to the top anymore when you search for "facebook".

Last alternative is, adding an additional sort rule:
1) public vs. sandbox
2) strict, exact name match
3) fuzzy name match
4) all others MySQL finds relevant

I am fine with either option (maybe the last one is the best though), I just don't want to have to change it twice a week....

Comment 17

[Fred Wenzel [:wenzel]]

Now that I wrote all this, the order 2) 1) 3) 4) seems to make even more sense: It'll show the experimental "diggler" on the top if you search for its name specifically. Followed by all public add-ons whose names match fuzzily, then the public ones with no name match, then experimental with fuzzy name match, and at last experimental ones with no name match.

How does that sound?

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

I've filed bug 446122 and bug 446467, and we've also got bug 291413 for the top-rated facet of search results' ordering; not sure if I should verify this one or not (i.e. are those spinoffs enough?)  Not sure what to do with Fred's suggestion(s) in comment 16 / comment 17.

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED, before this bug gets too unwieldy; let's just file (more) spinoff bugs.