{quote}
The crux of my question is when do you need to clear the indexing queue without having to clear the session?
{quote}
I see this method as part of the explicit indexing API where I would be able to clear the entities scheduled to be indexed via {{FullTextSession.index()}}. I am also not sure when exactly I would use it. I guess one could image an exception during indexing where as part of the exception cleanup one wants to clear the already scheduled work.
The other question is around event based indexing and semantics around {{Session.save()}} and {{Session.clear()}} (might belong to HSEARCH-1270). Assuming this code:
{code}
@Test
public void testSessionClearWithSave() throws Exception {
Session session = openSession();
Transaction tx = session.beginTransaction();
Foo foo1 = new Foo();
session.save( foo1 );
session.clear();
Foo foo2 = new Foo();
session.save( foo2 );
tx.commit();
session.close();
}
{code}
What is the result. Which {{Foo}}s end up in the database? Only {{foo2} or {{foo1}} and {{foo2}}. I was kind of assuming the former, but that is not the case. AFAICT both instances are persisted. Am I using {{clear()}} the wrong way or are the semantics different?
If the behaviour is expected, then I argue that indexing is correct, since both instances get indexed.
The other question is whether there is a semantic difference between {{Session.save}} and {{Session.persist}} when it comes to lifecycle events?
|
