Hi.

We've been talking on the JUG Milano mailing list about the chance to use HibernateSearch for indexing while persisting Map with hibernate instead of Pojo. I change one sample project to persist Map in less than an hour following hibernate core docs this morning. Now is time to make Hibernate Search work again.

The sample app already has tests that now the search tests are broken. I need to make them green again: I am on this exception:

java.lang.IllegalArgumentException: Entity to index is not an @Indexed entity: java.util.HashMap
at org.hibernate.search.impl.FullTextSessionImpl.index(FullTextSessionImpl.java:186)
at org.hibernate.search.jpa.impl.FullTextEntityManagerImpl.index(FullTextEntityManagerImpl.java:105)

Now I have different possible ways: read the doc about programmatically add HSearch: http://bit.ly/e9oo4q should be the first but I am also thinink: what about a generic "KeyValue" object where I can put @Indexed annotations over and where I can reuse all hibernate search annotations (and developer knowledge) without forcing me or other devs to use annotations with pojos and java when persisting maps?

We were talking about the possibility to adapt this model to a generic key-value store, I am experimenting with MongoDB actually. I am wondering about pros and cons of having a generic class with annotations.
The other way is: remove annotations and go the programmatic way, and there is the doc for that, I'll be back if I'll find problems.

I'd like to discuss about this solutions and the generic topic with the community.

Sumarizing: focus here is to persist Map on a RDBMS with hibernate, or also changing the storage with a document DB or even a Key-Value store. Over this, I want to keep Hibernate Search as indexing engine.

Hi ildella,
I've been thinking about this, the problem is that currently it's possible to use Search even without annotated entities, but the internal Worker still expects to deal with classes as type; and as the exception you posted proofs, nobody tried to do this before, so some work needs to be done.

Let's give some names at internals: there's an hibernate eventlistener named org.hibernate.search.event.FullTextIndexEventListener which catches events such as save, update, delete from hibernate core.
Events collected are sent to org.hibernate.search.backend.impl.TransactionalWorker, which queues things up into a org.hibernate.search.engine.WorkPlan, and uses some instances of org.hibernate.search.engine.DocumentBuilder to convert the data contained in each entity into a Lucene Document.

After you got a list of List<LuceneWork> (see org.hibernate.search.engine.WorkPlan.getPlannedLuceneWork() ) you're done with everything related to Hibernate Core, at least for indexing and not thinking about the MassIndexer yet, and all further processing is done via Lucene APIs, so for sure that part we can reuse as it currently is.

So if you are able to create the List<LuceneWork> you're basically set, and ready to use all other nice features such as all backends, clustering, IndexReader pools without the need to make more changes.
As you might have seen, many components can be replaced with alternative implementations, and while we ship some alternatives for common use cases (like DirectoryProvider has the in-memory version, the filesystem based, the Infinispan implementation), for some other cases we never found a use case for.
In your case I think that you might need to write a custom Worker implementation:
as you can see in org.hibernate.search.backend.WorkerFactory.createWorker(SearchConfiguration, WorkerBuildContext), if you define a new class implementing org.hibernate.search.backend.Worker you can have it replace the "annotated class oriented engine" with a new implementation more Map friendly.

I think it would also be possible to update the current implementation (TransactionalWorker) to support Maps, but I think it might be easier to experiment with a new one as you have much simpler work to do (avoid all code about reflection).

When you have your own Worker implementation, there are some other small patches to apply, like FullTextSession.index would need a little fix, and also the eventlistener will need a small fix, as they too expect objects to be of specific mapped types, but I expect these other cases easier to handle. In fact you can also try out your own eventlistener, disable the auto-registration of the stock implementation and register a different implementation, or extend it to override a subset of methods.


I hope yo have provided you with useful pointers. You should open a feature request on JIRA, we can then have comments on the issue and involve more people; I'm currently working on a high priority feature, but after I'm done with it I'll be glad to help you out with code, if you fork the project on github we can work on a branch you "own" and discuss details on the branch.
I might be able to provide you pointers here, but to make sure patches will be accepted we should discuss relevant changes on the mailing list, also you might find more help and suggestions from other developers and contributors.

Thanks Sanne for the exaustive reply.

I was thinking about this yesterday and I realized that my real primary target is persist over MongoDB and having a Lucene Index.
Using Maps instead of pojos is different target, something I'd like to achieve but it's seconday for now.

a simple self made "asMap", or using the really early stage spring-data is enough to store a pojos over MongoDB. So I have my hibernate mapped and annotated Pojo that does not need additional work to be indexed by lucene via HS.

At this point I just need to remove the part of hibernate that store the data in the relational DB. That's the road for the target one.
For the target two I'll need some more work on the diretion you pointed me out but it's a completely different topic and is more related to a design issue (too much pojo for what's just data).

I'll let you know about the development.

Hi,
yes this are our priorities too, first we want Hibernate working on different store engines.
You might join here: viewtopic.php?f=1&t=1008278

BTW it appears that basic CRUD is working fine currently, and Emmanuel is making progresses on Collections handling.