This project is read-only.


Resolve differences between Faceted Search results and MOSS Core Search Results


It would be helpful to resolve the differences between number of search results between the MOSS core search results and the faceted search results. These are often different because of the different ways in which the indexes are queried?

file attachments


leonidly wrote Mar 20, 2008 at 6:07 AM

Yes, the difference is due to the syntax. This is a good candidate to the next release.

wrote Mar 20, 2008 at 5:17 PM

wrote Apr 8, 2008 at 1:58 PM

wrote Apr 8, 2008 at 2:29 PM

wrote Apr 17, 2008 at 3:53 PM

wrote Apr 19, 2008 at 1:33 PM

wrote Apr 25, 2008 at 3:05 PM

wrote May 2, 2008 at 2:39 AM

wrote Jun 12, 2008 at 2:48 PM

wrote Jun 20, 2008 at 12:58 PM

wrote Jul 1, 2008 at 9:40 PM

wrote Jul 17, 2008 at 3:21 PM

leonidly wrote Jul 30, 2008 at 6:49 PM

2.5 release addressed the issue by changing the search query

wrote Jul 30, 2008 at 6:49 PM

Hikmer wrote Aug 24, 2008 at 11:31 PM

This doesn't appear to be fixed....I still can't understand how it is that you have facets that don't add up???? My users will freak! So sad I released this in production now I have to back pedal.

Ludvig wrote Oct 15, 2008 at 3:08 PM

I still have a problem with this.
Im using the latset version realeased 27 of september and I often get results where I have the facets saying it exist 10 on different facets and the search result shows 0. The problem that they are showing different number is not that critical for me but that it could show facets when no hits is not good. I guess you do a fulltext search in the facets and there is keyword search in the core serach result. But I have also tested your navigators with Ontolica which uses the full text search allowing wildcard search. But even here I can get the difference.

You are speaking about a featuer that say that core result and facet are syncronized. I would say it aint. How is this done? There is no like connection that i can choose between them what I can see.
This really important for us to get it working.

And for some boosting. Its except this an awesome addon.

Ludvig wrote Oct 16, 2008 at 9:59 AM

Im attaching an example of this. This is the worst case scenario. I could give you a lot more where they are totally out of sync.
I have now allso tested to check out the latest version from svn and compiled and tested this with the same result.

wrote Oct 16, 2008 at 9:59 AM

gbelzile wrote Nov 6, 2008 at 4:05 PM

Any plan to fix this problem? It seems to be still there.

wrote Nov 6, 2008 at 8:06 PM

wrote Nov 6, 2008 at 8:24 PM

sanketshah wrote Nov 6, 2008 at 8:28 PM

I am having the same problem, my core result web part and search faceted results and count didn’t match to each other.
It still there into new release 2.5

funeclipse wrote Nov 10, 2008 at 11:25 AM

I agree with this !

Solving this problem is a very good idea...

slowtalkinwalter wrote Nov 17, 2008 at 9:40 PM

From the testing that I've done, it looks like a lot of this discrepancy is due to the facets using an "or" query, when the core search results is doing an "and" query. When I do a search for Rumplestiltskin, I get 2 hits. When I search for Suncoast I get 6 hits. When I search for Rumplestiltskin and suncoast (results.aspx?k=rumplestiltskin+suncoast or k=rumplestiltskin%20suncoast) I get 8 hits. I haven't had my crew crack open the code yet. Maybe there was a plain English description of this problem elsewhere on the board, but I didn't find it. Hope this helps someone.

wrote Nov 17, 2008 at 9:46 PM

leonidly wrote Nov 23, 2008 at 1:33 AM

Another thing to remember is that unless you explicitely exclude user profiles People search is processed and accounts are counted by Facets. Core Search results exclude people by design.

wrote Nov 24, 2008 at 8:43 AM

lfastrup wrote Dec 3, 2008 at 8:59 AM

Specifying a fixed scope on the CoreResultsWebPart is not respected by the Faceted Search Web part. The problem in this situation is that the FSWP also shows facets found outside the fixed scope.

wrote Dec 3, 2008 at 9:00 AM

wrote Dec 21, 2008 at 5:13 PM

peterdk wrote Jan 6, 2009 at 1:35 PM

the scenario described by slowtalkinwalter is frustrating my users and blocks a company wide deployment. Is there a patch available or a starting point in the source code?

leonidly wrote Jan 7, 2009 at 2:27 AM

This was fixed in the latest build. Please confirm that you're running the latest and have Scope property defined as "All Sites" where required.

wrote Jan 12, 2009 at 2:13 PM

dmorgenthaler wrote Jan 12, 2009 at 2:14 PM

Since the last Build the scope parameter s= in url works fine but if I get the Core Result a scope the results in core dosn't match the results in FSWP!

wrote Jan 14, 2009 at 9:42 AM

slowtalkinwalter wrote Feb 6, 2009 at 12:19 AM

After testing the stock FS 2.5 and analyzing the hits, here are the reasons for the differences in hits and hit counts:
1) Stock FS 2.5 ignores scopes. It was picking up hits in other scopes, whereas the core search parts were constrained by scope. The FS number was thus usually bigger. This would cause a 'No Search Results' message sometimes when faceting. I think there's a fix for this posted already (
2) Stock FS 2.5 is doing an 'OR' search rather than an 'AND' search. This meant that the FS number again tended to be bigger.
3) The OOTB Search Statistics LIES about the number of hits. As you paginate through a given search, you'll actually see the reported number of hits change. After we downloaded the source and made some adjustments for 1 and 2, then what we found was that the OOTB Search Statistics number refined towards the number reported by FS 2.5 as you moved towards the end of the result set. E.g., if FS 2.5 reported 255 hits, then OOTB Search Statistics might report 300, or it might report 200. If you tried to manually paginate by manipulating the URL, say, http://portal/searchcenter/Pages/results.aspx?k=smith+jones&start1=281 (start1 bigger than the number reported by FS, smaller than the number reported by OOTBSS) then you'd find that you'd run out of hits - no results. If you changed start1 to a number slightly smaller than the number reported by FS, say start1=251, then you'd see that you were at the end of the result set since you only had half a page of hits.

Change the code to take care of #1 and #2 and then turn off "Display Total Number of Hits" in the OOTB Search Statistics property sheet.

peterdk wrote Feb 7, 2009 at 10:19 AM

issue seems to be solved in the latest 2.5 release for my environment. I'm using a dedicated seach page for a small and fixed scope (1000 documents), stemming is disabled for these Dutch documents. We've deployed it on the intranet production cluster last week. Thanks a lot!

peterdk wrote Feb 17, 2009 at 8:43 AM

Using v2.5 Dec release, keywords entered in the searchbox after a managed property (or managed properties) are neglected by the counters on the facet webpart.
Incorrect counters using
Property1:"Value1" keyword1 
correct counters using
keyword1 Property1:"Value1" 
also incorrect counters using
keyword1 Property1:"Value1" keyword2
(Same behaviour for multiple properties: correct results using -keyword1 Property1":"Value1" Property2:"Value2"-, incorrect results for -Property1":"Value1" Property2:"Value2 keyword1 -)

wrote Apr 16, 2009 at 9:06 PM

wrote Feb 14, 2013 at 3:41 AM

wrote May 16, 2013 at 8:10 AM

wrote May 16, 2013 at 8:10 AM

wrote Jun 14, 2013 at 7:52 AM