HSEARCH-1383 Ability to disable automatic indexing programmatically at the session level / HSEARCH-168 Ability to disable automatic indexing programmatically at the application level

[marko-bekhta]

https://hibernate.atlassian.net/browse/HSEARCH-1383
https://hibernate.atlassian.net/browse/HSEARCH-168

The filter is applied in the process method for indexing the plan for this first iteration, and then there's also usage of it in the event listener to reduce the amount of work.

[marko-bekhta]

So the idea of filtering inside the ORM event listener somewhat failed 🥲. Since we attach the listener to the session factory, it behaves more like an application filter rather than a session filter.
I suppose we can add checks to various add/update/delete methods of AbstractPojoTypeIndexingPlan to prevent from building up the state....

[yrodiere]

So the idea of filtering inside the ORM event listener somewhat failed

It can work, but you need the listener to delegate those checks to something that's session-bound.

I gave it some thought, and I think the best approach would be for you to pass the type context to HibernateSearchEventListener#getCurrentIndexingPlan/#getCurrentIndexingPlanIfExisting and have those methods return some type-specific indexing plan.

I created a branch to show what I mean, feel free to take those commits in your own branch and adapt them as necessary: main...yrodiere:HSEARCH-1383

[marko-bekhta]

Hopefully, it is a tad bit better now 🙈
by the way, I haven't used your suggestion on how to check if a type is an entity, as it didn't work as a check for a mapped super type, and I thought we wanted to give the user an option to pass these supertypes to this filter (see HibernateOrmTypeContextContainer.java#isManagedType() I'm not sure if there's a better way to check it, but if not maybe that's something to add to ORM?).

[yrodiere]

I thought we wanted to give the user an option to pass these supertypes to this filter

I don't think we do. I believe mapped superclasses can be interfaces, and that opens a whole can of worms due to multiple inheritance: what if a class extends two mapped "superinterfaces", one being included and the other being excluded?

Better keep it simple, IMO.

[marko-bekhta]

ohhh OK 🙈, then some changes are in order 😄 give me a moment 😃

[yrodiere]

Thanks! Here are a few comments, finally. Sorry for the delay.

[yrodiere]

Thanks, it's looking better but I would advise a few more adjustments. You might want to proof-read as well, as it seems some renamings were done only partially.

[yrodiere]

LGTM apart from two minor comments. Feel free to merge once they're addressed.
Thanks!

[yrodiere]

Thanks, LGTM, though I think I spotted an unnecessary check. Please have a look and then feel free to merge!

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
17 Code Smells

84.5% Coverage
0.0% Duplication

[yrodiere]

Merged, thanks!

[yrodiere]

Actually, not merged, GitHub is having problems...