-
Notifications
You must be signed in to change notification settings - Fork 15
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
deps: bump zeebe version to 8.1.9 #685
Conversation
Return type is not necessary, since return was always true, which is why it has been removed from the API. (cherry picked from commit bb4ba14)
This is a new method. To make the compilation pass, we need to implement it. However, this is not yet possible because we lack the ability to iterate starting from a specific key. Currently, all iterations start at the beginning of the column family. We need to add this ability in the upcoming commits. (cherry picked from commit 12a052a)
This is to be able to differentiate the prefix key from the startAt key. (cherry picked from commit 29b960a)
This method was only used in one spot and that one spot was only implemented by calling this one method. So by inlinging the method, it becomes more clear how whileTrue is actually implemented. This makes it easier to implement overloaded variations of whileTrue. (cherry picked from commit e4403b4)
This implements the whileTrue(startAtKey, visitor) method, by introducing a new whileEqualPrefix method that allows setting a startAt key. For the whileEqualPrefix method that does not take a startAt key, we can simply use the prefix key as the starting position. See line 221. This is similar to the implementation in Zeebe (see ref 1). To enable iterating starting at a specific key, we need to change the initial seek to use the startAt key instead of the prefix key. See line 240. This is inline with the implementation in Zeebe (see ref 2). The startAt key is just an arbitrary key. In order to use it in the seek, we need to prepend the logical column family id to the startAt key. See lines 237-238 and the method `keyWithColumnFamily` in `InMemoryDbColumnFamilyIterationContext`. This is inline with the implementation in Zeebe (see ref 3). For a more in-depth explanation please have a look at ref 4. References: 1. camunda/camunda@f227c32#diff-d12a85834691a282f898186d31bd219e4e96e0f996fe98a6f7faa4cb56fb088dR324-R325 2. camunda/camunda@f227c32#diff-d12a85834691a282f898186d31bd219e4e96e0f996fe98a6f7faa4cb56fb088dL340-R355 3. camunda/camunda@f227c32#diff-06cd30102e4af6da91ba5a3c3d43c65b2e257557da286d242b9758588c30cc43R118-R125 4. camunda/camunda#11785 (comment) (cherry picked from commit 210f510)
Some changes were made in Zeebe. The creation of the processors now requires an InterPartitionCommandSender directly, instead of a deploymentDistributionBehavior. Besides this it also requires an EngineConfiguration. (cherry picked from commit 18f43f2) Conflicts: engine/src/main/java/io/camunda/zeebe/process/test/engine/EngineFactory.java
This change was introduced to Zeebe, but not yet ported to ZPT. See: camunda/zeebe#eda221c1
@deepthidevaki I've cherry-picked these commits to align the 8.1.9 version with the 8.1.9 Zeebe Engine. Please have a look. EDIT: Note that 3ac70ad is not cherry-picked, but an additional fix that was needed. I've also applied that fix here. |
Thanks @korthout. Would you like someone else to review the PR? Otherwise you can approve and merge. |
Would be good just to verify. @remcowesterhoud Can you have a look? |
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.
LGTM 🚀
bors merge
Build succeeded:
|
Description
Bump zeebe version to latest patch 8.1.9