FIX JPAEventSource

[s4ke]

threadsafe queue to store all the data to be updated.

[s4ke]

the reason for this is that we can not reliably know in which order the events are being raised

[s4ke]

then make the JPAEventSource also the only way to interact with JPA events. (make the HSearchEventListener stuff default visible again)

[s4ke]

and maybe remove all the listenTo(...) logic from the HSearchEventListener to the JPAEventSource to then determine which eventconsumer wants what by giving them the listenTo(...) method

[s4ke]

annoyingly EclipseLink shouldn't trigger the events on em.flush() but when the transaction is commited...

[s4ke]

we have a way to make the index updates applied at commit time instead (if there is a transaction present) (for this we have to keep the changes or use hibernate-search's transaction mechanism for that)

[s4ke]

a version that would definitely work would look like this:

for every table that is index relevant we need a second table that holds all the id's of entites that need to be re-indexed. We poll from these tables every fixed amount of time and then reindex all the entities marked by the ids in those tables.

these tables have to be created via JPA by making an Entity class called Entity[Updates] annotated with @UpdatesFor({Entity.class, Entity2.class}) that uses the same ID class as the original Entity (for Bridge Table Entities we need all the IDs of the classes). These ID-Fields habe to be annotated with an annotation to mark them being the id for the given class (something along the lines of @IDFor(class = Entity.class, columnsInOriginal = {column}, columnsInUpdate={column])) so we can get the corresponding entity out of the table.

These tables are populated via triggers. These triggers can be dynamically generated by looking at the info in the @UpdatesFor annotation.