Hello I am looking for ways to extend NEST.
Any guidelines?
Personally I am not a fan of IQueryable
Fully implementing IQueryable_search endpoint and all the features that exposes is the reason why I have never attempted to implement it for NEST.
That said the guys from CenturyLink have been working on such an implementation for a while now:
https://github.com/CenturyLinkCloud/ElasticLINQ
@damieng who works on that is an expert LINQ implementor (ex-microsoft employee who worked on LinqToSql, EF (code-first)) so I have no intention of going NIH!
I would love to investigate if ElasticLINQ could play nice using NEST .Search() but its not a high priority at the moment.
Thanks for your answer.
I can agree with you. But when it comes to polyglot persistence and basic CRUD operations IQueryable makes sense since most applications tend to use NHibernate/EF which in turn implements IQueryable. I've already looked at ElasticLINQ but there is no nice abstraction of IQueryable(like NHibernate have with NhQueryable for example). And for unit-testing it would be nice to have an IQueryable implementation.
Originally when I wrote ElasticLINQ NEST was an all-in-one but now the low-level and query levels have been split into separate projects it might be worth me seeing again if there is a good way to integrate.
Hello damieng,
I would love some kind of integration. Basically what I am looking for is the IQueryable implementation but I also need the power from NESTs .Search() and mapping capabilities.
I tried something of my own in one of my projects by using both NEST and ElasticLINQ. But I gave up on the fact that I had to deal with two clients and two libraries. It would be great if you could just pass a common client or something to ElasticQueryProvider thus giving you the power of ElasticLINQs IQueryable implementation.
:+1:
@Mpdreamz I did find this: http://www.elasticsearch.org/guide/en/elasticsearch/client/ruby-api/current/_persistence.html
Is implementing that in .net fundamentally the same problem?
No, implementing LINQ is basically translating expression trees that look a bit like SQL represented as methods into an as-close-as-possible elasticsearch DSL query.