Re: Search problem on no2.php.net
| From: | Dave Barr | Date: | Mon, 11 Jul 2005 10:20:29 +0000 |
| Subject: | Re: Search problem on no2.php.net | ||
| References: | 1 2 3 4 | Groups: | php.mirrors |
| Request: | Send a blank email to php-mirrors+get-28704@lists.php.net to get a copy of this message | ||
Trond Arve Nordheim wrote:
On 7/10/05, Dave Barr <dave@php.net> wrote:- Mirrors that reply with "PHP: Variable Handling Functions - Manual":I researched this problem, this is what happens: - Must be using the sqlite lookup for this to occur. It does not occur using find_manual_page_slow() - a ref.* prefix has a search priority of 0 - a control-structures.* prefix has a search priority of 4 - The lower priority the better - As you can see just from this, "ref.var" supercedes "control-structures.for", but this isn't the problem, as "var" shouldn't be matching "for" in the first place. - metaphone("var") is "FR" - metaphone("for") is "FR" - metaphone matches get a worse priority, the problem? The priority they get is +1 of their usual priority, this means: - ref.var has a search priority of 0+1=1 for the search term "for" - control-structures.for has a search priority of 4+1=5 for the search term "for" - Thus, ref.var is returned when searching for "for".It seems to work on all mirrors I've tested except mine, though - I can't be the only one running with SQLite, can I? If this is a priority issue, it should happen everywhere. I'm not saying what you said isn't correct, I'm just curious :) Most mirrors reply with "PHP: for - Manual", except a few:
ca, dk2, ee, ee2, gr2, hu, is, id, id2, lu2, no2, yu, si, es, uk- Mirrors that reply with: 500 Internal Server Error:
in, in2, il, it2- Mirrors that reply with "PHP: Service not working":
sk- Mirrors I couldn't connect to:
au2, cn2As you can see, you are in the minority, but you are definitely not alone. Also, I made a mistake above, control-structures.for has a search priority of 4 for "for" instead of 5, as it doesn't need to use the metaphone equivilent "FR" (4+1). When the search is done, it searches for both the original pattern and its metaphone equivilent. Another solution could be to search for just the original pattern first, and if that fails to find anything then search for metaphones? This would avoid having to touch the prio's in the database. Dave