Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace CatchUpHooks with ContentRepositoryHooks #4992

Open
bwaidelich opened this issue Apr 15, 2024 · 0 comments
Open

Replace CatchUpHooks with ContentRepositoryHooks #4992

bwaidelich opened this issue Apr 15, 2024 · 0 comments
Assignees
Labels

Comments

@bwaidelich
Copy link
Member

bwaidelich commented Apr 15, 2024

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:

sequenceDiagram
  activate EventPersister
  EventPersister->>EventStore: load()
  activate EventStore
  EventStore-->>EventPersister: EventStream
  deactivate EventStore
  EventPersister->>ContentRepositoryHook: onBeforeBatch()
  rect rgba(200, 200, 200, .1)
  loop 
    EventPersister->>ContentRepositoryHook: onBeforeEvent(event, eventEnvelope)
    EventPersister->>Projection: apply(event, eventEnvelope)
    EventPersister->>ContentRepositoryHook: onAfterEvent(event, eventEnvelope)
  end
  end
  EventPersister->>ContentRepositoryHook: onAfterBatch()
  deactivate EventPersister

Migration of existing Hooks

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.

@bwaidelich bwaidelich added the 9.0 label Apr 15, 2024
@bwaidelich bwaidelich self-assigned this Apr 15, 2024
bwaidelich added a commit that referenced this issue Apr 18, 2024
@bwaidelich bwaidelich changed the title Rework CatchUpHooks Replace CatchUpHooks with ContentRepositoryHooks Apr 19, 2024
@bwaidelich bwaidelich changed the title Replace CatchUpHooks with ContentRepositoryHooks Replace CatchUpHooks with ContentRepositoryHooks Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

1 participant