What would you think of going for the second choice - to detect affecting fields automatically and allow people to add something similar to AssociateDirty - but disable the whole dirty-checking optimisation by default on each entity? We could make it an attribute at class level @Indexed(enableDirtyCheckingOptimisations=true).

And maybe an entity having @Transient properties which affect input of any index field (be it via @Field of custom bridges) should always be considered dirty, at least by default?

The dirty-checking optimization already seems disabled on entities which have a @Transient method that is indexed. That was the point of https://hibernate.atlassian.net/browse/HSEARCH-1096. See here in particular: https://github.com/hibernate/hibernate-search/commit/4918277bdace4070135140cb89194669ca8fb7e3#diff-a7dba6f969e60bb6ad97cd6879b33fefR486
The fact it was disabled is sensible, but it is precisely the reason I was having performance issues that I wanted to address with this new "substractive" annotation.

So yes, if the additive method is chosen (even if it's the other, actually), I agree that @Transient methods (and ClassBridge s) should disable dirty-checking optimization by default. This would have the added benefit of not changing anything for current users, irrespective of the solution ("additive" or "substractive") we choose.

I don't see the point of @Indexed(enableDirtyCheckingOptimisations=true), though. I think the current way of doing things ensures the index is always up-to-date, to there's no need for users to disable this optimization. The need is more about applying this optimization more often.

Now, on the choice of the solution itself. I agree the "additive" solution would be more intuitive. But:

1. I'm not sure I'll have the time to look into it anytime soon (especially because I don't know which special cases I'll have to handle, and there might be a lot).
2. The "substractive" solution, on the other hand, is almost ready to commit to the Hibernate Search project, simply because I had to find a quick fix for a client project where we started to have huge performance issues. It's already being used in production environment.
3. Maybe the two solutions are not mutually exclusive. Like I said above, in an entity with few fields but many @Transient methods, one would prefer to use the "substractive" solution, while in an entity with many fields but few @Transient methods, the contrary would be true. And I don't think using both solutions on the same entity would be problematic.