Problem with ActionEventEmitterEventStore and Projections

[prolic]

Currently it delegates the projection creation to the used event store implementation. This is a problem, as the wrapped event store is then not used in the projection itself, and you cannot attach listeners to it during projection's emit and linkTo.

$eventStore->createProjection($eventStore) would solve the issue (adding event store as optional parameter, which will only be set by action event emitter event store) - but this looks weird and might lead to some people injecting a complete different event store instance, which would be cleary wrong.

Ideas?

@codeliner @oqq @bweston92

[bweston92]

I'm not to sure I get the problem. $eventStore->createProjection($eventStore) could the createProjection not just pass $this ?

[prolic]

@bweston92 that's excatly the problem, that $this is passed.

see: https://github.com/prooph/event-store/blob/develop/src/ActionEventEmitterEventStore.php#L314 and https://github.com/prooph/event-store/blob/develop/src/InMemoryEventStore.php#L291-L303.

This way $actionEventEmitterEventStore->createProjection(...) will use InMemoryEventStore within the projection, not the ActionEventEmitterEventStore.

[codeliner]

tbh I've no idea :( thought about decoration or reflection but both is not an option here.
$eventStore->createProjection($eventStore) would be the only solution but it looks strange.

Question: Do we really need these projection factory methods in the event store interface? Why not set up projections with normal factories? This way it would also be possible to mix PostrgresEventStore with mongoDB projection?

[prolic]

In pdo-event-store I reuse the pdo connection, event stream table, and some other information, that is stored in private properties of the mysql/postgres-eventstore in the projection constructor. This way it's very easy to set up.

Using a distinct factory might be a solution however, that would not be that ugly. I will try to update this when I work on the pdo-event-store again and update it (remove abstract classes, as well). Latest should be this weekend.

[prolic]

Oh maybe something like this in event-store interface:

public function getProjectionFactory(): ProjectionFactory ?

This way this can be used by the action event emitter event-store.

Pro:

• clean solution

Con:

• it bloats the interface a little - but I think we can live with that.

Another possibility:

We don't add it to the interface, and the event store implementation simply uses it's hard-coded known factory. For the action event emitter, we inject that factory in the constructor.

Pro:

• no bloated interface, clean solution

Con:

• you have more configuration to do for the action event emitter event store - give him the factory classes in the config

[codeliner]

not bad!

I think my favorite is the first option: public function getProjectionFactory(): ProjectionFactory

[prolic]

one factory for all 3 (query, projection, readmodelprojection)? or one by one? this would mean adding 1-3 more methods to the interface.

[prolic]

having slightly more complex action event emitter event store config would make the interface more cleaned up.

[prolic]

@oqq @shochdoerfer @sandrokeil @bweston92 @basz your thoughts?

[sandrokeil]

Question: Do we really need these projection factory methods in the event store interface? Why not set up projections with normal factories? This way it would also be possible to mix PostrgresEventStore with mongoDB projection?

I think it's really important to mix an event store with an other projection store. Using a method getProjectionFactory() in the interface itself introduces new problems.

one factory for all 3 (query, projection, readmodelprojection)? or one by one? this would mean adding 1-3 more methods to the interface.

Can we use a default factory and put it to the \Prooph\EventStore\Projection\ProjectionOptions class. So it's optional configurable but works out of the box?

[shochdoerfer]

I think I would go the distinct factory route.