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.
>> # 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?
>
>> 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.
But let's discuss that, if you have some good points we can reject the issue.
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.
Moving HSEARCH-1270 out of the 4.4 plans, now replaced by:
HSEARCH-1425 - Introduce a FullTextSession.clearIndexingQueue method
Sanne
>
>> 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
