Is there any way (or hack, workaround, whatever) to disable automatic indexing on one of my entities when using JPA?

I have 20 or so entities with @Indexed. For one of them, I'd like to manually update the index since it's a versioned entity thats potentially quite large, and all I ever care about for search purposes is the latest version.

there's no "clean" support to do this, but as a hack/workaround you can disable automatic eventlistener registration, then extend

org.hibernate.search.event.impl.FullTextIndexEventListener

and register your implementation instead, which can skip what you want.
It really is a hack as we hope to get a better approach to do that and make that class final.

What do you mean by versioned, is it using Envers ? Maybe you could propose a solution to have this do the appropriate thing out of the box.

It's not using envers, it's my own home brewed versioning system.

I'm not sure if the approach you suggest would work, as it looks like EventSourceTransactionContext.getIndexWorkFlushEventListener explicitly checks for the FullTextIndexEventListener class. I suppose I could write in another implementation of it that doesn't, but then I'd start going down a fairly unpleasant rabbit hole with needing my own FullTextSessionImpl and so on.

As an aside, is there a recommended way of specifying the listeners in a JPA environment globally? Having to add it into every persistence.xml is a bit annoying.

It looks like this issue has cropped up many times for people. The ideal solution would be being able to control it per index as well as globally. Something like:

hibernate.search.autoregister_listeners=true (enable globally)
hibernate.search.myindex.autoregister_listeners=false (disable for a specific index)

With an annotation counterpart:

@Indexed(index = "myindex", autoregister-listeners = false)

that's an interesting concept, but there is a mismatch between entities and indexes since
* an index can be shared to multiple entities
* an entity can use multiple indexes (via sharding)
* the two above can be combined in many weird ways, making it complex to handle

So I wouldn't bind an enable/disable to the index name, but to the entity type.
Considering that, would you like to propose an API or even a patch for something more flexible?

I'm happy to work on a patch to add this functionality, if we can get consensus on how it should look from the user POV.

Given that HS works in a 'entity first' manner, you're right that it makes more sense to specify whether an entity should be automatically indexed or not, rather than have it be on an index (it doesn't make sense to want to exclude a shard, nor is it that useful to be able to exclude groups of entities if they happen to be in a specific index).

So given that, do you think that @Indexed is the wrong location for this annotations?

Since it's not an index based configuration, it doesn't make sense for it to go into search config (hibernate.properties and suchlike), but rather to go within the entity itself, and @Indexed to me still seems like the least unintuitive place to add this...

yes I agree about locating some option on @Indexed, just make sure it's clear that it's relating to the annotated class, not (directly) related to the index name.

For this kind of changes the best approach is to write a proposal of the new API to the developer's mailing list; see:
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Usually I'd suggest to make a proof of concept, with unpolished code and some tests, to make sure what you propose is actually implementable, and get a better grasp on how it would work, what the limitations are. Then you propose the API, we discuss the details like attribute names, annotations, etc ,and when that is settled by a broader agreement we can work together to polish the patch, and merge it for inclusion in the next release.