Hi Jirka, Welcome and many thanks for your interest in contributing to our projects!
2014-08-20 16:28 GMT+02:00 Jiri Holusa <jhol...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
