[hibernate-dev] Support for Elasticsearch in Hibernate OGM proposal

[Gunnar Morling]

Hi Jirka,

Welcome and many thanks for your interest in contributing to our projects!

2014-08-20 16:28 GMT+02:00 Jiri Holusa <jholusa at redhat.com>:

> Hi everybody,
>
> I'm Jirka Holusa and I work JDG QA (Infinispan) team, just for you to
> know, this email has nothing to do with JDG :)
>
> Currently, I looking for a nice topic for a diploma thesis and I came
> across one. I worked with Elasticsearch in my bachelor thesis and I thought
> it would be nice to integrate it with Hibernate.


> So I found Hibernate OGM and thought thaht I would like to develop the
> Elasticsearch module for Hibernate OGM. I talked to Emmanuel and Sanne and
> they pretty liked the idea, so they suggested to move the discussion here
> on dev list.
>

 +1

So for implementing support for a new datastore in OGM, you'd have to
implement the GridDialect contract basically. This is a very generic
contract which is responsible for persisting (and reading) tuples
(representing entities) as well as associations. In addition, there are
some "facets" which a grid dialect can implement optionally, namely support
for batching (processing several operations in one atomic datastore
invocation) and query support.

To get started with CRUD, I'd recommend to take a look at the CouchDB (and
MongoDB) dialect as I expect ES to be rather similar. For Couch we use
JAX-RS/Jackson to interact with the store and convert tuples to/from JSON
documents. I guess some parts of the CouchDB dialect could be extracted and
shared by both backends.

I would love to read all your suggestions/proposals/tip etc. The rough plan
> is to first implement the JPA API (therefor CRUD operations) and once this
> is finished, implement search capabilities via Hibernate Search API.
>

Ironically, search will be the more challenging part. As you know, HSearch
only supports direct Lucene access at this point. Ideally, that issue would
be resolved first (a very interesting topic for a diploma thesis on its own
right ;). Then we could simply plug-in HSearch for full-text queries
executed via ES. Note that in this case the complete entity can be obtained
from the search backend, I'm not sure whether that possibility is already
foreseen in HSearch?

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.


> I looking forward to your replies.
>

Regarding the diploma thesis, how would this exactly work? Are there e.g.
any restrictions in the ways the code you write as part of this can be
used, or are we meant to "supervise" parts of the thesis in any way? It'd
be interesting to learn more about the formal/administrative aspects of
this.

Hope this provides some food for thought. Just ping us here on the list or
#hibernate-dev on FreeNode to discuss any details.

>
> Cheers,
> Jirka
>

--Gunnar


> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>