we are currently evaluating Hibernate Search as replacement for our propriatary Spring LuceneManager. I really like the idea of solving performance critical queries with Lucene instead of DB queries and I've already worked on a commercial persistence layer that used exactly the same approach and worked great that way.

but here's the problem: i added a simple test-case to our product's test framework, to play around with Hibernate Search. The test case inherits from a general test-case that already sets up all the Spring/Hibernate architecture. During the setUp method already existing Hibernate objects are deleted from the underlying database (we wanna test several different db providers, not just hsqldb), meaning that there exists a transaction where first occurs an object update and than an object deletion. What cost me quite a lot of time was figuring out my first test-case failed (it just creates a simple persistent object and looks for it in the index) until i debugged down to DocumentBuilder where i found this code-piece:




in my case this leads to the following behaviour:

*) since the persistent object is updated during the init process the queue contains: [DELETE, ADD]
*) in the same transaction the object gets deleted but the above code piece causes document builder to ignore this circumstance. the queue should contain [DELETE,ADD,DELETE] or [DELETE] but contains [DELETE,ADD]. As a consequence the object isn't deleted from the underlying lucene index and the index is inconsistent

am i getting something wrong (didn't find anything about this issue in the bugtracking system/forum)?

Hum, I need to think about it hard. The choice I made was to prevent any circularity issue (due to how @ContainedIn needs to operate). maybe we could infer something from the operation type and ordering or simply add some special operation type when contained in is involved.
Open a JIRA issue please.

In the mean time, you probably should clear your data in one transaction and operate your test in another. It makes much more sense since it tests the reality of your use case.

Thanks for the fast response. I am going to write a simple Hibernate-only test-case and will open a JIRA issue.

The data is already cleared in a single transaction, but due to multiple relationships to other objects the persistent object gets updated before its finally deleted:

-- transaction begin
--- remove object from relationship1 --> causes update event
...
--- remove object from relationship2 --> causes update event
...
--- finally delete object --> causes delete event
-- transaction commit

The updates causes the behaviour described above, if there would only be an object deletion without the updates, the index would be in perfect state.