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.