-
Notifications
You must be signed in to change notification settings - Fork 592
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
Apply event-sourcing to the message start event subscription processors #6510
Conversation
06ace74
to
7e2e96e
Compare
7e2e96e
to
2e23d82
Compare
2e23d82
to
51d47ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me 🎉
Please have a look at my two comments.
engine/src/main/java/io/zeebe/engine/processing/message/Subscriptions.java
Outdated
Show resolved
Hide resolved
|
||
CLOSE((short) 2), | ||
CLOSED((short) 3); | ||
CREATED((short) 0), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing we might want to consider here is whether we want to reuse the old ordinals. E.g. if you set Correlated to 4 and deleted to 3, we could read more of the old records. Not sure there is a point though, as there are ordinals of the old records which we cannot read anymore anyway.
Another option is to keep all the old ordinals, reassign the reused ones, deprecate the ones we won't use anymore. Then we could write out exceptions when we encounter an unsupported ordinal.
Again, not sure it is worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually, I would agree. But since the version will not be compatible anyway, we don't need to care.
51d47ee
to
c7459a7
Compare
bors r+ |
6510: Apply event-sourcing to the message start event subscription processors r=saig0 a=saig0 ## Description * align the message start event subscription intents `OPENED` and `CLOSE` and rename them to `CREATED` and `DELETED` * avoid writing and process `CREATE` and `DELETE` commands * instead, the deployment processor writes the events directly * replace the command processors by the event appliers ## Related issues closes #6183 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [ ] The changes are backwards compatibility with previous versions * [ ] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [ ] New tests are written to ensure backwards compatibility with further versions * [ ] The behavior is tested manually * [ ] The change has been verified by a QA run * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com>
Build failed: |
bors retry |
6510: Apply event-sourcing to the message start event subscription processors r=saig0 a=saig0 ## Description * align the message start event subscription intents `OPENED` and `CLOSE` and rename them to `CREATED` and `DELETED` * avoid writing and process `CREATE` and `DELETE` commands * instead, the deployment processor writes the events directly * replace the command processors by the event appliers ## Related issues closes #6183 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [ ] The changes are backwards compatibility with previous versions * [ ] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [ ] New tests are written to ensure backwards compatibility with further versions * [ ] The behavior is tested manually * [ ] The change has been verified by a QA run * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com>
Build failed: |
* align the message start event subscription intents OPENED and CLOSED and rename them to CREATED and DELETED * avoid writing CREATE and DELETE commands. instead, write the events directly when processing a new deployment.
c7459a7
to
5d853e0
Compare
bors |
bors r+ |
6510: Apply event-sourcing to the message start event subscription processors r=saig0 a=saig0 ## Description * align the message start event subscription intents `OPENED` and `CLOSE` and rename them to `CREATED` and `DELETED` * avoid writing and process `CREATE` and `DELETE` commands * instead, the deployment processor writes the events directly * replace the command processors by the event appliers ## Related issues closes #6183 ## Definition of Done _Not all items need to be done depending on the issue and the pull request._ Code changes: * [ ] The changes are backwards compatibility with previous versions * [ ] If it fixes a bug then PRs are created to [backport](https://github.com/zeebe-io/zeebe/compare/stable/0.24...develop?expand=1&template=backport_template.md&title=[Backport%200.24]) the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. `backport stable/0.25`) to the PR, in case that fails you need to create backports manually. Testing: * [x] There are unit/integration tests that verify all acceptance criterias of the issue * [ ] New tests are written to ensure backwards compatibility with further versions * [ ] The behavior is tested manually * [ ] The change has been verified by a QA run * [ ] The impact of the changes is verified by a benchmark Documentation: * [ ] The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.) * [ ] New content is added to the [release announcement](https://drive.google.com/drive/u/0/folders/1DTIeswnEEq-NggJ25rm2BsDjcCQpDape) Co-authored-by: Philipp Ossler <philipp.ossler@gmail.com>
Build failed: |
bors r+ |
Build succeeded: |
Description
OPENED
andCLOSE
and rename them toCREATED
andDELETED
CREATE
andDELETE
commandsRelated issues
closes #6183
Definition of Done
Not all items need to be done depending on the issue and the pull request.
Code changes:
backport stable/0.25
) to the PR, in case that fails you need to create backports manually.Testing:
Documentation: