I had a suspicion that this would be a feature of AxonDB I had a look at ‘FilteringEventStorageEngine’ suggestion & what I could tell from the javadoc alone it’s not a solution:
Implementation of EventStorageEngine that delegates to another implementation, while filtering
* events as they are appended. This prevents certain events to be stored in the Event Store
Ours is not an append time problem we’re trying to solve but rather selective reads per tracking-processor, or I might have misunderstood the suggestion you proposed.
With some high-level guidance on your part I’d be more than willing to submit a PR. I had a look at some possible integration points to build the solution on:
* (Jdbc)EventStorageEngine.getTrackedEventData(…) - Key to this would be to have a custom token that holds onto a list of event types that will be used to build an IN clause from.
* Custom (GapAware)TrackingToken - as mentioned above used to hold list of event types we’re interested in.
* Custom TrackingEventProcessor - that should pass event type list to token when invoking storageEngine.getTrackedEventData(…)
* EventProcessorBuilder - inits above mentioned tracking processor with list of events. A possible solution of obtaining list of event types might be to perform a “reverse-lookup” from beans that form part of processing group & then use reflection interrogate all the event handlers that are registered to obtain the list of event types.
This is based on my very limited understanding on how things fit together so I might be completely off the mark. I already encountered some constraints & questioned my understanding on:
* GapAwareTrackingToken is essentially final (private constructor)
* How would batching be implemented as only a subset of events are read & global index might not be applicable.
* No idea how parallel processing will be effected.
Anyways any guidance would greatly be appreciated!