First of all, I just wanted to say that I just started working with Solr and really like the results I'm getting from Solr (in terms of performance, flexibility) as well as the good responses I'm getting from this group. Hopefully I will be able to contribute in way way or another to this wonderful application in the future!
The current issue that I'm having is the following ( I tried not to be long-winded, but somehow that didn't work out :-) ): I'm extending StandardRequestHandler to no only show the counts per facet-value but also the top-N results per facet-value (where N is configurable). (See http://www.nabble.com/Result-grouping-options-tf4522284.html#a12900630 for where I got the idea from). I quickly implemented this by fetching a doclist for each of my facet-values and appending these to the result as suggested in the refered post, no problems there. However, I realized that for calculating the count for each of the facetvalues, the original standardrequesthandler already loops the doclist to check for matches. Therefore my implementation actually does double work, since it gets doclists for each of the facetvalues again. My question: is there a way to get to the already calculated doclist per facetvalue from a subclassed StandardRequestHandler, and so get a nice speedup? This facet-falculation seems to go deep into the core of Solr (SimpleFacets.getFacetTermEnumCounts) and seems not very sensible to alter for just this requirement. opinions appreciated. Some additional info: I have a requirement to be able to limit the result to explicitly specified facet-values. For that I do something like: select? qt=toplist &q=name:A OR name:B OR name:C &sort=sortfield asc &facet=true &facet.field=name &facet.limit=1 &rows=2 This all works okay and results in a faceting/grouping by field: 'name', where for each facetvalue (A, B, C) 2 results are shown (ordered by sortfield). The relevant code from the subclassed standardRequestHandler is below. As can be seen I alter the query by adding the facetvalue to FQ (which is almost guarenteed to already exist in FQ btw.) Therefore a second question is: will there be a noticable speedup when persuing the above, since the request that is done per facet-value is nothing more than giving the ordered result of the intersection of the overall query (which is in the querycache) and the facetvalue itself (which is almost certainly in the filtercache). As a last and somewhat related question: is there a way to explicity specify facet-values that I want to include in the faceting without (ab)using Q? This is relevant for me since the perfect solution would be to have the ability to orthogonally get multiple toplists in 1 query. Given the current implementation, this orthoganality is now 'corrupted' as injection of a fieldvalue in Q for one facetfield influences the outcome of another facetfield. kind regards, Geert-Jan --------------------------- if(true) //TODO: this needs facetinfo as a precondition. { NamedList facetFieldList = ((NamedList)facetInfo.get("facet_fields")); for(int i = 0; i < facetFieldList.size(); i++) { NamedList facetValList = (NamedList)facetFieldList.getVal(i); for(int j = 0; j < facetValList.size(); j++) { NamedList facetValue = new SimpleOrderedMap(); // facetValue.add("count", valList.getVal(j)); DocListAndSet resultList = new DocListAndSet(); Query facetq = QueryParsing.parseQuery( facetFieldList.getName(i) + ":" + facetValList.getName(j), req.getSchema()); resultList.docList = s.getDocList(query,facetq, sort,p.getInt(CommonParams.START,0), p.getInt(CommonParams.ROWS,3)); facetValue.add("results",resultList.docList); facetValList.setVal(j, facetValue); } } rsp.add("facet_results", facetFieldList); } -- View this message in context: http://www.nabble.com/showing-results-per-facet-value-efficiently-tf4600154.html#a13133815 Sent from the Solr - User mailing list archive at Nabble.com.
