On 1 Jan 2013, at 8:09 PM, Sanne Grinovero <sa...@hibernate.org> wrote:
> On 1 October 2013 15:41, Hardy Ferentschik <ha...@hibernate.org> wrote:
>>
>> 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?
>
> 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
