You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the CatchUpHookInterface is a bit weird and flaky.
It's a very low-level API even though I expect it to be one of the main extension points for Neos 9.x.
One of the main issues is the relation to one specific projection because that leads to low-level dependencies and quirky constructs like the ProjectionsAndCatchUpHooksFactory.
Suggestion
I suggest to drop the concept in favor of ContentRepositoryHooks that can be registered globally (per CR instance).
With the architectural changes of #4746 this should allow for the same kind of flexibility, i.e. a hook is invoked before an event is applied and afterwards, so the implementation can access the read model(s) in a controlled manner:
Changing an existing CatchUpHookInterface implementation should be rather trivial, because the interfaces will be mostly similar I assume
CatchUp of individual projections
The above should work fine, as long as all projections are on the same checkpoint.
This is the case by default (with the reworked catch up mechanism).
But what if it's not, for example because a new projection was added or replayed?
My current gut feeling is: We simplify things greatly if we assume the default case (and make sure that's always given).
That would mean: When replaying/catching up individual projections, hooks are not triggered.
The text was updated successfully, but these errors were encountered:
This is no longer valid. With the updated #4746 the plan is to basically keep CatchUpHooks (maybe with a slight modification that allows them to differentiate between "replay" and "catchup")
The current implementation of the
CatchUpHookInterface
is a bit weird and flaky.It's a very low-level API even though I expect it to be one of the main extension points for Neos 9.x.
One of the main issues is the relation to one specific projection because that leads to low-level dependencies and quirky constructs like the
ProjectionsAndCatchUpHooksFactory
.Suggestion
I suggest to drop the concept in favor of ContentRepositoryHooks that can be registered globally (per CR instance).
With the architectural changes of #4746 this should allow for the same kind of flexibility, i.e. a hook is invoked before an event is applied and afterwards, so the implementation can access the read model(s) in a controlled manner:
Migration of existing Hooks
Changing an existing
CatchUpHookInterface
implementation should be rather trivial, because the interfaces will be mostly similar I assumeCatchUp of individual projections
The above should work fine, as long as all projections are on the same checkpoint.
This is the case by default (with the reworked catch up mechanism).
But what if it's not, for example because a new projection was added or replayed?
My current gut feeling is: We simplify things greatly if we assume the default case (and make sure that's always given).
That would mean: When replaying/catching up individual projections, hooks are not triggered.
The text was updated successfully, but these errors were encountered: