Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Sun, 10 Feb 2013 09:23:13 +0000 (UTC)
From: "Shai Erera (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12631221.1360227813190.270695.1360488193227@arcas>
In-Reply-To: <JIRA.12631221.1360227813190@arcas>
References: <JIRA.12631221.1360227813190@arcas>
Subject: [jira] [Resolved] (LUCENE-4759) Remove FacetRequest.SortBy
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LUCENE-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shai Erera resolved LUCENE-4759.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 5.0
                   4.2
    Lucene Fields: New,Patch Available  (was: New)

Committed to trunk and 4x.
                
> Remove FacetRequest.SortBy
> --------------------------
>
>                 Key: LUCENE-4759
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4759
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/facet
>            Reporter: Shai Erera
>             Fix For: 4.2, 5.0
>
>         Attachments: LUCENE-4759.patch
>
>
> FacetRequest.SortBy lets you specify two sort-by: ORDINAL and VALUE. While VALUE is the default (and breaks ties by ordinal), it's not very clear what's the use of SortBy.ORDINAL.
> In practice, if you choose to do that, you'd get the first K categories that are the descendant of the requested one, from smallest to highest, or vice versa. But that seems quite useless ... someone could just traverse the counts array (for instance) and filter out all counts==0? Or also, someone can write a FacetResultsHandler which does that...
> My motivation to remove that is to reduce the number of PQ combinations we have: MinValue, MaxValue (SortBy.VALUE, SortOrder.ASCENDING/DESCENDING) and MinOrdinal, MaxOrdinal. Now there are 4 PQs and I'd like to separately split them out to PQs that handle int vs float. Because today these PQs call Double.compare(), which you need to for floating-point values, but is just a waste for integer values.
> So removing SortBy will both simplify the API and halve the number of PQs we need to write. Plus ... it doesn't seem such a useful option, to let the user even spend 10 seconds to read the differences between VALUE and ORDINAL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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