Projector status

[Bas Kamer]

While fixing #179 I think I might have stumbled upon some deeper problem.

Suppose I have no projections running and with help of the projection manager I instruct a projection to stop. The remote status is changed to 'stopping'. This is weird in itself because it was not running, but ok.

So now the projection is started to begin projecting event. Upon startup the active projector will see the 'stopping' status and update it's status to idle and exits promptly. The result is a not running projector, just one that might have overwritten an 'stopping' state for a possibly running projector. (without the PR from #180 you would even loose stream positions state.)

I wonder if we are missing a 'stopped' state to complement the idle state of an active projector. When a active projector exits it should set the status to stopped. Then the stopping status should only be acted on by active (running, or idle) projector.

If a Projector with a status of 'stopping' is started, why would it be allowed to persist anything? It should either wait until stopped and continue as an active projector or exit immediately.

This is kind of hard to wrap inside my head. Not even taking into account the locking mechanism of the projectors. So, this is only a call for feedback for now.

Edit: My mistake. Currently 'idle' is equivalent to 'stopped', so that's fine I guess. However I would like to be able to pause a projector via the process manager.

Why? While testing it helps when I am able to pause a projector, wait for it to be actually paused (via fetchProjectionStatus) then restore the events store from some fixtures, reset (or fast forward without emitting events) the projector and then activate it again.

[Sascha-Oliver Prolić]

I will check this when I have some time. Sascha-Oliver Prolic Am Mo., 5. Nov. 2018 um 16:51 Uhr schrieb Bas Kamer < [e-mail]>:

…

While fixing #179 <#179> I think I might have stumbled upon some deeper problem. Suppose I have no projections running and with help of the projection manager I instruct a projection to stop. The remote status is changed to 'stopping'. This is weird in itself because it was not running, but ok. So now the projection is started to begin projecting event. Upon startup the active projector will see the 'stopping' status and update it's status to idle and exits promptly. The result is a not running projector, just one that might have overwritten an 'stopping' state for a possibly running projector. (without the PR from #180 <#180> you would even loose stream positions state.) I wonder if we are missing a 'stopped' state to complement the idle state of an active projector. When a active projector exits it should set the status to stopped. Then the stopping status should only be acted on by active (running, or idle) projector. If a Projector with a status of 'stopping' is started, why would it be allowed to persist anything? It should either wait until stopped and continue as an active projector or exit immediately. This is kind of hard to wrap inside my head. Not even taking into account the locking mechanism of the projectors. So, this is only a call for feedback for now. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#181>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvHCfRCU3BYTL8rU1aOzIzmV4swnPks5ur_wGgaJpZM4YOAOY> .

[Sascha-Oliver Prolić]

To me pause is the same as stop, so we have this already, no?

[Bas Kamer]

Not really.

Consider having a long-running process managed by supervisord. There is a difference between that being stopped and the projection being (what I would call) paused.

I would like to keep the process running but the projector inactive (via the process manager) so I can reset the event store with fixtures in tests or development. Currently, I need to stop it, do my tests or import fixtures and then manually restart the process...

Additionally: I have built my projectors such that I can specify if events are actually being projected. That is useful to fast-forward process-manager projections. Of course, I would like to see that also build into the projectors themselves. A status 'fast-forward' which automatically goes to 'idle' when it has reached the tip.

Then I also noticed some dislike (in prooph/event-store#352 (comment)) around the integration of the projections and event-store.

So, all in all, maybe some refactoring might be needed. But please consider these requests are a mere collection of ideas for now.

[Sascha-Oliver Prolić]

When this is not a bug (as of now), can we close this issue? v8 will be different anyway.

…

On Sat, Nov 10, 2018, 16:39 Bas Kamer ***@***.*** wrote: Not really. Consider having a long-running process managed by supervisord. There is a difference between that being stopped and the projection being (what I would call) paused. I would like to keep the process running but the projector inactive (via the process manager) so I can reset the event store with fixtures in tests or development. Currently, I need to stop it, do my tests or import fixtures and then manually restart the process... Additionally: I have built my projectors such that I can specify if events are actually being projected. That is useful to fast-forward process-manager projections. Of course, I would like to see that also build into the projectors themselves. A status 'fast-forward' which automatically goes to 'idle' when it has reached the tip. Then I also noticed some dislike (in prooph/event-store#352 (comment) <prooph/event-store#352 (comment)>) around the integration of the projections and event-store. So, all in all, maybe some refactoring might be needed. But please consider these requests are a mere collection of ideas for now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#181 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvCBqheGWNbwoKbWtLg4-LOe5HuP7ks5utpC0gaJpZM4YOAOY> .