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

Recognize 'store' and 'restore' updates #75

Open
medikoo opened this issue Nov 21, 2016 · 0 comments
Open

Recognize 'store' and 'restore' updates #75

medikoo opened this issue Nov 21, 2016 · 0 comments
Assignees

Comments

@medikoo
Copy link
Owner

medikoo commented Nov 21, 2016

Currently when records are loaded to the engine, it's not obviously clear wether they come from actions that just happen or are one already save and now are being restored.

Theoretically it can be assumed by stamp, but:

  • It's not certain how old stamp should be to be assumed as restore one.
  • It's not reliable approach as store records, could ones that waited on a client-side for a day-long

Use case are email notifications as sent in server side (master) process, which should not be send in case of restored records. Current way of dealing with it, is configuration of two-step triggers, where we require at least a tick-gap between them to approve change as a trigger for event.

The valid solution would be probably to mark event injections batches as either store or restore kinds. Those kind of batches never happen as mixed, and we could in our listeners detect wether state change was triggered by store or restore batch.

@medikoo medikoo self-assigned this Nov 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant