[hibernate-dev] HSEARCH-638 and other Search fixes.. another RC?

[Sanne Grinovero]

I had created a testcase for HSEARCH-638 [1] quite some time ago, and
Davide was now so kind to take it over and implement the solution
which is almost ready in a pull request.

In my opinion,  HSEARCH-638 is a performance bug and should be fixed.
When we last talked about it, Emmanuel was not considering it being
bug, as it was exactly expressing it's original intention.. I believe
we settled by saying it would be fine to change the behaviour, BUT he
would not consider it a bug fix but an API change as it would affect
possible users: indeed that's correct, as it changes what is exactly
included in the index, but how I was seeing the index mapping I doubt
anybody was relying on it.

So now we have a fix, and the project lead considers it an API change.
This was the original reason for me when I made the tests for it, to
not provide a solution yet, as it would need to wait for 4.0 .. now we
have the solution so I think we should rather merge it now than to
wait as it might be considered an API change (although I'm not overly
convinced of that).

Problem is that it's a bit late in the 4.0 train. If you think it's
acceptable to make another RC soon, then I'd love to include this and
also propose a solution for HSEARCH-598 (MassIndexer freezes when pool
size is too low), as I have a POC for it but it's not trivial so I
won't send a pull request (nor spend more time on it) unless we'll
make another RC.

If we could, I'd include two other API changes:
 - HSEARCH-800 Should we move ORM related APIs to
org.hibernate.search.orm? Today they are in org.hibernate.search
 - HSEARCH-795 Move some of SearchFactoryImplementor from spi to impl
(and move SPI level contracts up)

should these otherwise be rejected?

Sanne

1 - Limit graph traversal by @ContainedIn to the minimum required path
- https://hibernate.onjira.com/browse/HSEARCH-638