Hi,

I was excited to find a document detailing integration of lucene with hibernate (http://www.hibernate.org/138.html) as I was planning on using lucene in the near term. I am currently working on integrating the two, but came across a minor concern with the document.

The document's second solution, using interceptors (which looks to be the better of the two to me), suggests creating an interface called Searchable that exposes three methods: getIndexWriter(), getIndexReader(), and getDocument(). This interface is applied to your domain objects and the interceptor checks to see if the given entity is an instance of the Searchable interface. If so, it uses these helper methods to update an index.

So far, I have managed to keep my domain objects extremely simple. Basically, they contain state information and no more. They don't know about Hibernate and they don't know about Lucene. Now, introducing this interface causes the domain objects to become aware of Lucene (and the object's clients, unfortunately, as the interface exposes public methods).

Is this appropriate? Would it make more sense to store the Lucene related code in the DAO layer instead of in the domain objects themselves? This is more of a philosophical question versus a technical one, but I would be interested in hearing what others think or have done in their projects.

If you know exactly what objects have to be searched, you can also leave the interface out, and do all calculations in the Interceptor.

After some more thought and considering your comments (thank your for the feedback) I think I will create a Searchable interface that has a getFields() method. This way I can pass back a map of field names to values allowing search using Lucene or another search engine without coupling it to my domain objects. I will add the logic to persist and retrieve indices in the interceptor, which as you suggested seems like a logical place.

Figured I would post my thoughts in case someone else wants integrate Lucene and Hibernate and runs into similar questions.

If you want a more generic method, you can for example also use getClassMetadata() to get all persistent fields instead of a getFields() Method. Don't know what your requirements are exactly.