lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3192) SortField.INT / SortField.FLOAT inconsistency with DocValues
Date Sat, 11 Jun 2011 12:10:58 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13047890#comment-13047890
] 

Uwe Schindler commented on LUCENE-3192:
---------------------------------------

This comment is not really related to this issue, but could be done together:

We should make SortField types an ENUM in trunk. We can change API and those integer constants
are type unsafe.

For most code this change would not lead to compile failures, only code that assigns the types
to a variable/field. In all other cases code like new SortField("field", SortField.INT) could
work like it was before (if we add replicas of the enum constants to SortField, else it would
change to new SortField("field", SortField.Type.INT). 

The getComparator method should be moved to the enum and return a comparator without switch
statement.

> SortField.INT / SortField.FLOAT inconsistency with DocValues
> ------------------------------------------------------------
>
>                 Key: LUCENE-3192
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3192
>             Project: Lucene - Java
>          Issue Type: Wish
>            Reporter: Uwe Schindler
>            Assignee: Simon Willnauer
>
> When reviewing sorting by DocValues I found the following naming inconsistency, which
shoulc be fixed.
> # DocValues are always Longs or Doubles, but it uses SortField.INT and SortField.FLOAT
> # If you enable docValues in SortField but not use not SortField.INT / SortField.FLOAT,
it will use FieldCache without informing the user e.g. by Exception
> \\I would wish to fix this in any of the following ways:
> - as a comment TODO notes, create new types for docvalues and remove UseDocValues setter:
SortField.INT_DOCVALUES, Sort.FLOAT_DOCVALUES (using the naming INT/FLOAT from the general
DOCVALUES API). Ideally there should be also Sort.BYTESREF_DOCVALUES ? This would be more
consistent, as getCompataor would be only a big switch as it was before.
> - use more "correct" SortField.LONG and SortField.DOUBLE and throw Exception if doc values
is enabled, but a totally different SortField type is used. The Exception can be thrown in
SortField.getComparator(). A second problem with SortField.INT instead of LONG is that when
you request sort values to be filled into FieldDocs, the type there is suddenly Long, that
may be totally confusing.
> - make SortField.LONG==SortField.INT(maybe also ==BYTE==SHORT) use also docvalues if
enabled by using the same comparator. If DocValues incompatible type is used, throw Ex in
getComparator()
> I would prefer solution #1, especially as I dont like SortField to be modifiable (useDocValues
setter...). Solution #2 is also fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


Mime
View raw message