You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2015/06/25 21:27:04 UTC

[jira] [Created] (LUCENE-6609) FieldCacheSource (or it's subclasses) should override getSortField

Hoss Man created LUCENE-6609:
--------------------------------

             Summary: FieldCacheSource (or it's subclasses) should override getSortField
                 Key: LUCENE-6609
                 URL: https://issues.apache.org/jira/browse/LUCENE-6609
             Project: Lucene - Core
          Issue Type: Improvement
            Reporter: Hoss Man


{{ValueSource}} defines the following method...

{code}
  public SortField getSortField(boolean reverse) {
    return new ValueSourceSortField(reverse);
  }
{code}

...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}} containing a {{double[]}} based on the {{FunctionValues}} of the original {{ValueSource}}.

meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a {{ValueSource}} around {{DocValues}} for the specified field.

But neither {{FieldCacheSource}} nor any of it's subclasses override the {{getSortField(boolean)}} method -- so attempting to sort on something like an {{IntFieldSource}} winds up using a bunch of ram to build that {{double[]}} to give users a less accurate sort (because of casting) then if they just sorted directly on the field.

is there any good reason why {{FieldCacheSource}} subclases like {{IntFieldSource}} shouldn't all override {{getSortField}} with something like...

{code}
  public SortField getSortField(boolean reverse) {
    return new SortField(field, Type.INT, reverse);
  }
{code}

?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org