[
https://issues.apache.org/jira/browse/SOLR-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188477#comment-13188477
]
Peter Sturge commented on SOLR-1672:
------------------------------------
Some optimizations/changes to the faceting code have stopped this patch from
working (I think it was in 3.2, but it was right when the version numbers were
changing/merging). Definitely won't work out-of-the-box in 4.0. These changes
mean that the forward-sorted facets are sorted in reverse order, rather than an
'idf-type' facet sort.
It's been something I've wanted to look at fixing for ages now - just don't
have any spare cycles to devote to it.
The priniciple of this patch is still valid, it breaks because of some code
changes in the same module(s) (can't remember what they are off the top of my
head).
Bypassing the optimization bits if the facet operation is a reverse sort order
request may be one option, but some care would need to be taken to be sure.
> RFE: facet reverse sort count
> -----------------------------
>
> Key: SOLR-1672
> URL: https://issues.apache.org/jira/browse/SOLR-1672
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.4
> Environment: Java, Solrj, http
> Reporter: Peter Sturge
> Priority: Minor
> Attachments: SOLR-1672.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> As suggested by Chris Hosstetter, I have added an optional Comparator to the
> BoundedTreeSet<Long> in the UnInvertedField class.
> This optional comparator is used when a new (and also optional) field facet
> parameter called 'facet.sortorder' is set to the string 'dsc'
> (e.g. &f.<facetname>.facet.sortorder=dsc for per field, or
> &facet.sortorder=dsc for all facets).
> Note that this parameter has no effect if facet.method=enum.
> Any value other than 'dsc' (including no value) reverts the BoundedTreeSet to
> its default behaviour.
>
> This change affects 2 source files:
> > UnInvertedField.java
> [line 438] The getCounts() method signature is modified to add the
> 'facetSortOrder' parameter value to the end of the argument list.
>
> DIFF UnInvertedField.java:
> - public NamedList getCounts(SolrIndexSearcher searcher, DocSet baseDocs, int
> offset, int limit, Integer mincount, boolean missing, String sort, String
> prefix) throws IOException {
> + public NamedList getCounts(SolrIndexSearcher searcher, DocSet baseDocs, int
> offset, int limit, Integer mincount, boolean missing, String sort, String
> prefix, String facetSortOrder) throws IOException {
> [line 556] The getCounts() method is modified to create an overridden
> BoundedTreeSet<Long>(int, Comparator) if the 'facetSortOrder' parameter
> equals 'dsc'.
> DIFF UnInvertedField.java:
> - final BoundedTreeSet<Long> queue = new BoundedTreeSet<Long>(maxsize);
> + final BoundedTreeSet<Long> queue = (sort.equals("count") ||
> sort.equals("true")) ? (facetSortOrder.equals("dsc") ? new
> BoundedTreeSet<Long>(maxsize, new Comparator()
> { @Override
> public int compare(Object o1, Object o2)
> {
> if (o1 == null || o2 == null)
> return 0;
> int result = ((Long) o1).compareTo((Long) o2);
> return (result != 0 ? result > 0 ? -1 : 1 : 0); //lowest number first sort
> }}) : new BoundedTreeSet<Long>(maxsize)) : null;
> > SimpleFacets.java
> [line 221] A getFieldParam(field, "facet.sortorder", "asc"); is added to
> retrieve the new parameter, if present. 'asc' used as a default value.
> DIFF SimpleFacets.java:
> + String facetSortOrder = params.getFieldParam(field, "facet.sortorder",
> "asc");
>
> [line 253] The call to uif.getCounts() in the getTermCounts() method is
> modified to pass the 'facetSortOrder' value string.
> DIFF SimpleFacets.java:
> - counts = uif.getCounts(searcher, base, offset, limit,
> mincount,missing,sort,prefix);
> + counts = uif.getCounts(searcher, base, offset, limit,
> mincount,missing,sort,prefix, facetSortOrder);
> Implementation Notes:
> I have noted in testing that I was not able to retrieve any '0' counts as I
> had expected.
> I believe this could be because there appear to be some optimizations in
> SimpleFacets/count caching such that zero counts are not iterated (at least
> not by default)
> as a performance enhancement.
> I could be wrong about this, and zero counts may appear under some other as
> yet untested circumstances. Perhaps an expert familiar with this part of the
> code can clarify.
> In fact, this is not such a bad thing (at least for my requirements), as a
> whole bunch of zero counts is not necessarily useful (for my requirements,
> starting at '1' is just right).
>
> There may, however, be instances where someone *will* want zero counts - e.g.
> searching for zero product stock counts (e.g. 'what have we run out of'). I
> was envisioning the facet.mincount field
> being the preferred place to set where the 'lowest value' begins (e.g. 0 or 1
> or possibly higher), but because of the caching/optimization, the behaviour
> is somewhat different than expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
