2014-08-22 14:01 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 22 Aug 2014, at 10:34, Jiri Holusa <jholusa(a)redhat.com> wrote:
An alternative which may be a bit simpler and give quicker success for
simplistic queries would be to implement an ES backend of our pluggable
HQL/JP-QL parser. We already have implementations of this which take HQL
queries and translate them into corresponding MongoDB/Neo4j queries, so the
same should be doable for ES. But this wouldn't really carry semantics of
full-text queries (fuzzy search etc.) as one could get it via HSearch and
might expect for a backend such as ES.
Hmm, first approach seems to me a better way to do it, but as you said,
HSearch has to be
"undependent" on Lucene first. So I will start with CRUD and see where I
can get. Maybe
after that, something around HSearch and Lucene will be resolved, so than
I could decide
whick approarch to use.
Gunnar, the direct HQL->ES-QL work is not as trivial as it seems. I don’t
think ElasticSearch can search on fields that are not explicitly indexed.
(Jiri correct me if I’m wrong). So we would need to guess or anticipate
which field wants to be indexed and how “transparently”. Not the best of
settings.
Interesting, I really need to take a closer look at ES and its APIs.
How does it react when searching on an un-indexed field? If we can detect
the situation and raise a meaningful exception indicating that an index is
missing so a given query can't be run (could even be done during start-up
for named queries), then I'd say that's good enough, at least for a first
iteration? In particular if we add support for @Index so a user can react.
As said that solution would only be a work-around until we can delegate
that task to HSearch (which then would have the same challenge probably).
Btw. it's the same with Cassandra apparently, you also need to index
up-front the columns targeted in queries.
--Gunnar