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