Introduce a FullTextSession.clearIndexingQueue method

I think I've sketched a good proposal for https://hibernate.atlassian.net/browse/HSEARCH-1270#icft=HSEARCH-1270

IMO not a high priority atm though. We have much bigger fish to fry.

we agree this is to reject right?

+1

I think I've sketched a good proposal for HSEARCH-1270, so assuming we'll fix that one in future, we agree this is to reject right?

Another point is that persist() while having other issues does not require an early flush to the db as the id is not returned.

I did forget to read https://hibernate.atlassian.net/browse/HSEARCH-1270#icft=HSEARCH-1270 and I see it as a valid use case. But it seems to be a cheap workaround for the lack of index transactions. We could make clear() work in such a way that solves the user problem or make clear() work consistently with the ORM notion (i.e. what is flushed is flushed and reduce my memory consumption).

There is no obvious winner it seems.

save() happens to be different if the id generation uses column id. In this case, ORM must persist the entity right away because save() returns the identifier. In this case, the entity is stored and the index operation is in the queue. Clearing the indexing queue in this case will make the index inconsistent with the database (unless the DB is rolled backed).

This is quite common I think, also because when such an entity is persisted which needs a generated id, the whole persistence context is flushed (not just that entity), which means we get all persist events collected in Search's Queue.

So in some ways, clear() is fine by not clearing the queue, or maybe it should force a queue flush before actually clearing.

Good point. But are we going to argue that Session.clear() is inconsistent? It probably is, but seems to be useful. Trying to think about when it's useful, you're probably right that people want to Session.flush() first, they can do the same with the indexing backend which makes this feature indeed redundant.