[FEATURE] Support GeoDistanceSort

[michael-budnik]

Elastic.Clients.Elasticsearch version: 8.0.0-beta.6

Description of the problem including expected versus actual behavior:
I'm migrating (well, trying) one of our smallest APIs to 8.x.
In one of our calls we're sorting on distance from a point.
I've managed to get to this

.Sort(new[] { new SortCombinations(
      SortOptions.GeoDistance(new GeoDistanceSort
          {
              Field = (Expression<Func<MyClass, object>>)(x => x.Address.Coordinates),
              Order = SortOrder.Asc,
              Location = new List<GeoLocation>() {new GeoLocation() /* esPostcode.Lat, esPostcode.Long */ },
              DistanceType = GeoDistanceType.Arc
          }))
  }));

As you can see there a few problems with it.

1. Field should probably just be a generic expression of TDocument. I've noticed this issue in other places as well.
2. Can't provide coords. GeoLocation is an empty class.
   SortCombinations should probably be singular as constructor accepts only single SortOption.

Expected behavior
Should be able to specify lat lon.
Should be able to specify field expression easier.

Also question going forward.
I could easily add several more tickets like this but not sure what are the expectations for this 'beta phase'.
What kind of stuff do you expect to be reported at this stage?

[michael-budnik]

Ok, I've just discovered that there is Infer.Field<T> which allows me to do this:

Field = Infer.Field<MyClass>(x => x.Address.Coordinates)

I think the TDocument should be passed down somehow regardless.
Currently .Sort only accepts IEnumerable<SortCombinations> and the generic type information from Search<TDocument> is lost.

I could try and contribute but I don't think the code generator is part of this repo.

[stevejgordon]

Thanks for raising this, @michael-budnik.

Yes, Infer.Field is the best option in this case currently. The lack of fluent descriptor-based use of Sort is a work item on my list to enhance the generated union types. Right now, this API is inconvenient but usable. Once the fluent syntax is present, the TDocument type can flow down properly.

The GA of this new code-generated client will launch with support for a more limited API surface. Right now, geo-based types are not making the final cut. The latest rc.1 release removed the empty types, and I'm working to remove properties and types blocked by those missing types. The GeoDistance sort option will be one of those being removed in the next release. Geo-based types will be a high priority for subsequent releases, as I know these will block a subset of consumers from migrating.

Also question going forward.
I could easily add several more tickets like this but not sure what are the expectations for this 'beta phase'.
What kind of stuff do you expect to be reported at this stage?

The feedback you've been providing is extremely useful and much appreciated. It helps me to prioritise the remaining work to areas that I know are blocking consumers such as yourself. If you have time to raise blockers, I'd certainly welcome that.

FYI - I'm currently working on release notes and details of what is missing from the initial release when compared to NEST and 7.x. I'll be including some warnings for migration around the initially limited API surface.