Hey Gunnar,
On Thu, Jan 28, 2016 at 6:52 PM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
They in turn pull in Lucene in a version which potentially differs
from the Lucene version used by Hibernate Search itself. Also I wanted
to leave the door open for supporting multiple (potentially
incompatibly altered) versions of ES backends, say ES 2 and a future
ES 3.
All in all, these advantages outweigh the slightly simpler usage of
the DSL to me.
Yeah, I understand your concerns. Apart from the more complicated usage,
I'm afraid building raw JSON is going to be harder to maintain. We only do
simple things atm and I don't find the JSON manipulation very readable nor
very solid. It's going to be worse when we will add aggregations for
faceting and so on.
As for the dependencies, I could take a look at shading the necessary
classes for the builders and see if we can come up with something clean? I
don't know if it's something acceptable for an Hibernate project.
It doesn't solve the multi versions thingy but if they change the API, it's
going to be quite ugly to generate different JSON queries anyway, don't you
think?
> One of the challenges waiting for us will be to transform the
Lucene
> Filters into proper Elastic Search queries
I haven't looked into filters yet, but it's high on my agenda.
Do you think it's more difficult than transforming actual queries?
Btw. the ES PoC allows to pass in plain ES queries, at some point
these should be allowed to contain filter clauses, too (this might
even work already, haven't tried it).
Yeah I saw you could inject native ES queries and that's also something
that worries me with the raw JSON approach. I find it much more
user-friendly to provide an API to build the queries.
(Using these various discussions to adjust how I work and be more compliant
with the Hibernate way of life :))
--
Guillaume