[hibernate-dev] HSEARCH-1270 : indexing (still) happening after Session#clear()
Sanne Grinovero
sanne at hibernate.org
Mon Sep 30 17:00:27 EDT 2013
I'm having a half-baked solution for HSEARCH-1270, and it looks like I
can't do better than that without waiting for HHH-8577 to be included
in ORM [JIRA links at the bottom].
# The problem described by HSEARCH-1270
After the user has enqueued some indexing operations in Hibernate
Search's Worker, if he then invokes Session.clear() the queue is not
cleared.
I realize that clear() might not be as popular as most other methods
on Session, still I consider this an annoying limitation: it
introduces an inconsistency in the index and the user might not even
realize the mistake, and neither do we have an opportunity to warn
him.
# Partial solution
This is working well, and the test passes:
https://github.com/Sanne/hibernate-search/compare/HSEARCH-1270?expand=1
#Why it's not complete
The test requires to invoke the clear() operation *after* having
wrapped the Session in a FullTextSession.
In other words, if I'm just using the Session the bug would still manifest.
#What now
Considering that we can't do better than that - at least without
patching ORM with HHH-8577 - would you still merge such a patch?
I would propose to merge it, and add a warning in the docs, at least
the user has an option to workaround the issue.
The downside is that so far, at least Session and FullTextSession
behave consistently.. was that a good thing?
Another approach to the problem could be to provide an explicit
FullTextSession#clearIndexingQueue()
I think I'd like that, especially as it can be useful in other
situations, for example to avoid triggering any indexing operation for
a specific transaction.
Also, it would be a good companion for
FullTextSession#flushToIndexes()
-- Sanne
https://hibernate.atlassian.net/browse/HSEARCH-1270
https://hibernate.atlassian.net/browse/HHH-8577
More information about the hibernate-dev
mailing list