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

On 30 Jan 2013, at 11:00 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 1 Jan 2013, at 8:09 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 1 October 2013 15:41, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: >> >> On 30 Jan 2013, at 11:00 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; 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? > > No, it's a general problem. Pseudo-code inspired from my testcase: > > FullTextSession s = Search.getFullTextSession( openSession() ); > s.getTransaction().begin(); > persistDrink( s, "Water" ); > s.clear(); > persistDrink( s, "Espresso" ); > s.getTransaction().commit(); > > void persistDrink(Session s, String drinkName) { > Drink d = new Drink(); > d.setName( drinkName ); > s.persist( d ); > } > > If you run that, two Drinks "water" and "espresso" will be indexed, > but only espresso is committed to the database. Nasty. Really? So assuming event based indexing is occurring there. We won't get the event until commit is called, right?

So you are saying in this case we are still getting two PostInsertEvents even though the first event got "cleared". Btw, is there a difference between persist and save? I randomly took LuceneQueryTest and modified the test as you described. At least with save I only got a single event (for the book created after the clear).

>>> # 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. > > Does the above example affect your opinion? No. See above. >>> Another approach to the problem could be to provide an explicit >>> >>> FullTextSession#clearIndexingQueue() >> >> I think that is the better solution. > > I'll send a pull request to provide this as a new feature, but it > doesn't technically resolve > the HSEARCH-1270 issue: we're not accurately matching all operations happening > on the database, which I consider a violation of the project promise. This depends on whether automatic indexing is working as it should. Using Session.save I was not able to re-produce the semantics you describe. I am not sure yet whether persist behaves differently. Assuming that you indeed get two PostInsertEvents in your scenario, I would argue that we are dealing with a bug in ORM which should be addressed there. > Good to have #clearIndexingQueue() anyway as there might be cases in which it's > useful even not just as a workaround: there have been feature requests > to temporarily disable indexing on a Session for performance reasons. ok > Moving HSEARCH-1270 out of the 4.4 plans, now replaced by: > HSEARCH-1425 - Introduce a FullTextSession.clearIndexingQueue method Why did you move it out?

IMO we would provide FullTextSession.clearIndexingQueue for HSEARCH-1270 and that's it.

--Hardy