The impression I got looking at the Hibernate API was that it was trying to keep the Lucene index “hidden”.

Is this a fair asessment?

Regarding the philosophy part, it ties with my previous statement. Compass is open and flexible enough to be used in many different ways, one of them is similar to how Hibernate Search works.

Compass adds support for atomic transactions on top of Lucene. Which is the core for its performance benefits and fast updates. There is more information in Compass reference manual. The next version will also come with an XAResource implementation (though not supporting recovery).

I agree that Hibernate Search is at its infant stage, and that competition if very good. Compass is driven by user demand as well, and I am guessing that many of its features will be required from Hibernate Search as well. Anyhow, just wanted to make things clear with respect to the post on the Lucene mailing list.

A couple of comments:
There is a way in Hibernate Annotation to plug an XML metadata facility to replace/override annotations. So I guess when someone will need the feature, it should be straightforward.

About retrieving managed objects.
I do believe it is a better model, but that’s pure opinion.
Writing the small wrapper you’re talking about is trivial until you start thinking about the 1+ n problem. I have work around it somehow, and plan to go beyond when the fetch profile will be exposed to the Hibernate API.
You do not have to reach the DB with Hibernate if used in conjunction with the second level cache or even better because of the conjunction use of the persistence context.

I really like the idea of having your data in your database, if you want a local copy of your DB, then fine, the retrieval “by id”, should be just as fast as a Lucene index object reconstruction.

I think you’ve got a point: Compass is about indexing whatever placing Compass as the central API for object/resource retrieval
Hibernate / Hibernate Search is about using an ORM and indexing/searching the domain model. The angle is quite different in it’s philosophy.

The idea of giving a degraded version of the domain model is something I want to avoid for sure (unless asked explicitly through a query). If at some point I support object hydration form the index, I’ll make sure to use the lazy loading mechanism of Hibernate to make it transparent to the end user.

When you say atomic transaction you refer to full 2PC including the DB transaction (or other resources) or just the indexes?
I believe the latter.
Regarding a transactional behavior of the Lucene indexes, I’d better see that resolved by the Lucene project (there are some improvements going on I believe). Most people I discussed with are perfectly happy with the current behavior of Lucene, esp since I don’t think there is no true Lucene XAResource out there so a full 2PC including multiple heterogeneous resources is out of reach.

Comparing Hibernate Search and Compass is for sure unfair: give me some time ;-)
More seriously, I’m driven by use case and user demand, you can cover a bunch of usecases already with Hibernate Search. Some of the features you’ve listed are on my radar, I don’t see a clear strong use case for some others, and I do have some features of mine that I want to explore first.

“much more performant” Maybe, but why? :-)

Competition is good, and like I said, the user demand came from people having checked Compass. Both cover the problem through different angles.

Cheers

Emmanuel

Cheers