On 30 Jan 2013, at 11:00 PM, Sanne Grinovero <sa...@hibernate.org> wrote:
> 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]. Can you make a use case example. Clearing the queue makes only sense in the case where the indexing API is used, right? > # 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. Not sure I would expect that Session.clear has in impact on the manually queued indexing objects. > #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? No. I am not yet convinced that Session.clear should have the semantics you are implying. > Another approach to the problem could be to provide an explicit > > FullTextSession#clearIndexingQueue() I think that is the better solution. > 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() +1 --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev