Sanne Grinovero Catching up on some questions:
remember also to make it possible to use multiple fields of different "type", e.g. to sort both by distance and by surname.
Yes it works, see the code proposal
> allow to pass custom comaprator (has to be script for ES)?
Maybe only in future? I'd keep our DSL simple and targeting the simple use cases, people can use the native APIs for the more exotic needs. Also a custom comparator would probably break on the compatibility whims of upgrading Lucene / upgrading ES versions so I think it would be nice to "draw the line" of what Search helps with in terms of stable supported APIs vs when the user is using something "native".
For info I think the DSL is extremely simple and can super easily accommodate these use case. You won't save time by reducing the scope. You will definitely make it harder to introduce new things. Comparable is Java SE's API so it would be stable. The real question is whether to expose it when Elasticsearch might not be able to support it easily (without plugins / scripts).
> support missing value (first, last, custom value when absent) => native Lucene seems to have more limitations on the custom value than ES.
+1 but let's only expose on the common API what is clearly supportable by both.
That's the problem, it is not entirely clear to me what is supported by Lucene, it's all vague.
sort mode for multi values (min, max, avg, sum, median) => is it supported by native Lucene?
I think it wouldn't be too hard with a combination of collectors and custom comparators but I'd keep this as an optional feature for the future.
> reverse order > sort by distance of a point (Coordinate and lat / long) > sort by distance with custom distance computation (distance_type in ES), what about Lucene native?
I'd not expose custom distance computation on this API.
Any specific reason? Again on the DSL it's a trivial method call. Lucene implementation seems doable (I've asked Nicolas for a second pair of eyes).
> sort by distance from multiple points provided and multiple points in the documents (multi-value)? (that's ES) a way to back up to native Sort or Elasticsearch JSON "sort" for advanced use cases
It's a good point but I'd rather leave the API open for further extension. We're not removing the current capabilities to use "native sort" ? I think people with special needs should use that rather than the DSL, as I don't see how we can promise automatic type conversion and all that while keeping it both correct and easy to use.
Check out my proposal on the DSL, it does support a mix of native and non native naturally I think.
> Does it make sense to sort by SCORE and then by a specific field Sanne Grinovero ?
Sounds like one would rather customise the scoring? I'd again leave such odd needs to the existing and/or APIs, to not encourage it.
I don't think it is so odd. The question is for a given score, can one further refine the ordering. And does that make sense. One use case I can see is offering a predictable ordering all the time.
> Does distance support missing value? Can it? And if yes, is it limited to first / last?
I'm not sure if that would work. I guess missing coordinates might be interpreted as some specific zero coordinate, but that would still be treated as a specific position. The first/last part probably doesn't make sense as it's on a sphere...
I don't quite get it right. You could pass a reference value which would be used for documents with missing values. But on the Elasticsearch API, it's unclear whether yon can pass coordinates or not. But first / last seems easily implementable. It has nothing to do with the geometry, it just means, put the documents with missing values first or last in the result set. |