I have talked to Sanne about this and at first I wanted to allow the usage of Lucene queries. But he told me, this would come with the problem of relying on Lucene playing nice with the classes. And reliably supporting all Query-Types like this will definitely be hard.

CustomBehaviour is no good class name. You are right, but that can easily be refactored. And yes, in HSearch-ORM the place for this method would indeed be the FullTextSession (In my example I was talking about my API that does not rely on Hibernate-sessions, sorry for mixing that up).

Allowing the purging of Ids would indeed be nice. That would also require a new WorkType.

As of the deleteByQuery(...) with a Lucene Query as the argument: I don't know whether we can reliably convert from Lucene Queries to a serialized version and back and if it works, we can not for sure tell whether that will change in newer releases of Lucene. That's the general idea behind my "CustomBehaviour" stuff. Instead of not telling the users we could face problems we make sure they know that this is an expert feature which requires them to think before they do stuff.

In fact we could allow both methods in the FullTextSession. One with the projection + purge (short: PP) approach and one with the custom behaviour. PP should suffice for most use cases (with not so many deletes) and the CustomBehaviour (short: CB) approach could be used for more beefy tasks. What do you think about that?