-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[FEATURE] Source, SourceIncludes & SourceExcludes to support lambda targeting types & list #7825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@TheFireCookie Hi! Can you please specify the workaround that you use, please? |
For now I've just written those 2 extensions methods public static class SourceIncludesExtensions
{
public static SearchRequestDescriptor<TDocument> SourceIncludes<TDocument>(this SearchRequestDescriptor<TDocument> searchRequestDescriptor, params Expression<Func<TDocument, object>>[] sourceSelectors) where TDocument : class, new()
{
var sources = sourceSelectors.Select(e => (Field)e).ToArray();
searchRequestDescriptor.SourceIncludes(sources);
return searchRequestDescriptor;
}
public static GetRequestDescriptor<TDocument> SourceIncludes<TDocument>(this GetRequestDescriptor<TDocument> searchRequestDescriptor, params Expression<Func<TDocument, object>>[] sourceSelectors) where TDocument : class, new()
{
var sources = sourceSelectors.Select(e => (Field)e).ToArray();
searchRequestDescriptor.SourceIncludes(sources);
return searchRequestDescriptor;
}
} |
Just want to mention the "official" way of achieving this: var sd = new SearchRequestDescriptor<MyDocument>();
sd.SourceIncludes(new Expression<Func<MyDocument, object>>[] {
x => x.Id,
x => x.name
}); However, I agree that a direct overload might be a good idea and therefore leaving this issue open as a reminder. |
Thanks a lot! |
The "official" seems too noisy for no added benefits for my taste but I didn't know we could write it like that, thanks for the heads up! |
Would be great if we could get this example out on the official documentation. I have been finding it difficult to migrate NEST 7.XX to Elastic.Clients.ElasticSearch 8.XXX. |
If you have specific questions, you can ask me if you want. I've finished migrating my project :) |
Feel free to drop me specific questions as well. Improving the documentation is high up on my todo list and I'm already collecting all kinds of useful code snippets that will end up in the docs at some point. |
I agree with @jade-lucas comment, I'm having problems grasping the new way of "talking to Elasticsearch" compared to how this worked in Nest. Maybe I've missed some kind of basic explanation of the architecture in the new client? The code snippets you talk about @flobernd would probably be very helpful to get access to. Any idea about when these will be available? An example of a query I want to migrate to the new client, a MatchAll-query that in Nest looks like this (fieldNames being a list of strings):
How do I translate this to using the new client? |
var fieldNames = new List<string> { "abc", "def" };
var indexAlias = "my-index";
await elasticsearchClient.SearchAsync<T>(sd => sd.Index(indexAlias).Query(q => q.MatchAll()).Size(10000).SourceIncludes(fieldNames.ToArray())); |
Is your feature request related to a problem? Please describe.
I'm frustrated upgrading from 7 to 8 because in the include/exclude & general source filtering in NEST, we could work with lambda pointing to properties of a specific document (mydoc => mydoc.MyField), in the new ES8 client, we can only work with list of strings and the mapping is not easy.
NEST:
Describe the solution you'd like
Handling of the list (in addition of array etc) on the Fields class
Handling of the .NET lambda targeting type properties
Describe alternatives you've considered
Right now I'm using workaround of course :)
The text was updated successfully, but these errors were encountered: