Where is this API going?

Our ultimate goal is to be more independent of Lucene internal API. Currently, most of our machinery is based on Lucene API (we build our index with Lucene Documents for instance) and this has to change.

It's a Search 6 thing though.

Is this API going to support native sorts?

Native sorts are important. The fact is that Elasticsearch brings a lot of power to the user and it is really important to allow the user to use this power.

Here is what Emmanuel answered when I raised this very issue:

We could do that but I think that should tie with the generification of the DSL to support different backend outputs (namely Lucene, ES and Solr. But that one can only happen in 6.

So we should do it the dirty way for now and revisit that later.

Should we keep andByIndexOrder/andByScore

+1 to keep them. I also thought they might be useful.

Should we keep in(Unit)

Maybe we could simply provide a fixed value for Elasticsearch (probably meter) and document that?

In the long term, we will probably need to be able to define backend specific options but it might not be a priority for now.

Is the byDistanceFromSpatialQuery(Query) method making sense

It's a useful shortcut. If we can provide a useful error message if the user is not providing a spatial query, I think it's worth it. If it's going to be cryptic, probably not.

Do we want to support sorting on unmapped fields

I think it can be considered an acceptable limitation to always sort on common fields. I wouldn't enforce it though so that it continues to work as before for Lucene.

It would be something to keep in mind for Search 6.