Was there a solution here? Is there a ticket related to the sort=max(FIELD)
solution?
-brian
--
View this message in context:
http://lucene.472066.n3.nabble.com/Sorting-on-multiValued-fields-via-function-query-tp2681833p3340145.html
Sent from the Solr - User mailing list archive at Nabble.com
+1 for both Chris's and Yonik's comments.
On Thu, Mar 17, 2011 at 3:19 PM, Yonik Seeley
wrote:
> On Thu, Mar 17, 2011 at 2:12 PM, Chris Hostetter
> wrote:
>> As the code stands now: we fail fast and let the person building hte index
>> make a decision.
>
> Indexing two fields when one could work
On Thu, Mar 17, 2011 at 2:12 PM, Chris Hostetter
wrote:
> As the code stands now: we fail fast and let the person building hte index
> make a decision.
Indexing two fields when one could work is unfortunate though.
I think what we should support (eventually) is a max() function will also
work on
: But if lucene now can sort a multi-valued field without crashing when there
: are 'too many' unique values, and with easily described and predictable
: semantics (use the minimal value in the multi-valued field as sort key) --
: then it probably makes more sense for Solr to let you do that if yo
Aha, oh well, not quite as good/flexible as I hoped.
Still, if lucene is now behaving somewhat more predictably/rationally
when sorting on multi-valued fields, then I think, in response to your
other email on a similar thread, perhaps SOLR-2339 is now a mistake.
When lucene was returning com
By the way, this could be done automatically by Solr or Lucene behind the
scenes.
Bill Bell
Sent from mobile
On Mar 17, 2011, at 9:02 AM, Bill Bell wrote:
> Here is a work around. Stick the high value and low value into other fields.
> Use those fields for sorting.
>
> Bill Bell
> Sent fro
Here is a work around. Stick the high value and low value into other fields.
Use those fields for sorting.
Bill Bell
Sent from mobile
On Mar 17, 2011, at 8:49 AM, Yonik Seeley wrote:
> On Wed, Mar 16, 2011 at 6:08 PM, Jonathan Rochkind wrote:
>> Also... if lucene is already capable of sortin
On Wed, Mar 16, 2011 at 6:08 PM, Jonathan Rochkind wrote:
> Also... if lucene is already capable of sorting on multi-valued field by
> choosing the largest value largest vs. smallest is presumably just
> arbitrary there, there is presumably no performance implication to choosing
> the smallest
I agree with this and it is even needed for function sorting for multvalued
fields. See geohash patch for one wY to deal with multivalued fields on
distance. Not ideal but it works efficiently.
Bill Bell
Sent from mobile
On Mar 16, 2011, at 4:08 PM, Jonathan Rochkind wrote:
> Huh, so lucene
Huh, so lucene is actually doing what has been commonly described as
impossible in Solr?
But is Solr trunk, as the OP person seemed to report, still not aware of
this and raising on a sort on multi-valued field, instead of just
saying, okay, we'll just pass it to lucene anyway and go with luce
On Wed, Mar 16, 2011 at 5:46 PM, Chris Hostetter
wrote:
>
> : However, many of our multiValued fields are single valued for the majority
> : of documents in our index so we may not have noticed the incorrect sorting
> : behaviors.
>
> that would make sense ... if you use a multiValued field as if
: However, many of our multiValued fields are single valued for the majority
: of documents in our index so we may not have noticed the incorrect sorting
: behaviors.
that would make sense ... if you use a multiValued field as if it were
single valued, you would never enocunter a problem. if yo
Heh heh, you say "it worked correctly for me" yet you didn't actually have
multi-valued data ;-) Funny.
The only solution right now is to store the max and min into indexed
single-valued fields at index time. This is pretty straight-forward to do.
Even if/when Solr supports sorting on a mult
Hi David,
It did seem to work correctly for me - we had it running on our production
indexes for some time and we never noticed any strange sorting behavior.
However, many of our multiValued fields are single valued for the majority
of documents in our index so we may not have noticed the incorre
Hi Harish.
Did sorting on multiValued fields actually work correctly for you before?
I'd be surprised if so. I could be wrong but I think you previously always
got the sorting affects of whatever was the last indexed value. It is indeed
the case that the FieldCache only supports up to one indexed
15 matches
Mail list logo
