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

Separate mutable and immutable states #6233

Merged
2 commits merged into from
Feb 2, 2021
Merged

Separate mutable and immutable states #6233

2 commits merged into from
Feb 2, 2021

Conversation

saig0
Copy link
Member

@saig0 saig0 commented Jan 29, 2021

Description

  • extract mutable and immutable interfaces of the states
    • mutable interfaces are placed in the package io.zeebe.engine.state.mutable
    • immutable interfaces are placed in the package io.zeebe.engine.state.immutable
    • mutable interfaces have the prefix Mutable*State
    • immutable interfaces have no prefix - following common conventions (e.g. like Scala/Kotlin collections)
    • the implementations have the prefix Db*State - to indicate that they are based on the ZeebeDB
  • flatten the hierarchy of states
    • ZeebeDb give access to all states
    • avoid long call chains
  • move methods to the responsible states
    • following the single responsibility principle
    • avoid feature envy

Hints for the Reviewer

  • no need to look over all changes - I just extracted the interfaces with the IDE
  • no new JavaDoc for the interfaces - we can add the JavaDoc later iteratively when migrating the processors
  • no additional improvements to keep the changes small
  • the Sonar warnings exist before

Related issues

closes #6170

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 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:

  • 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

@saig0 saig0 marked this pull request as ready for review January 29, 2021 14:08
* extract mutable and immutable interfaces of the states
* flatten the hierarchy of states
* move methods to the responsible states
Copy link
Member

@korthout korthout left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes make me very happy. The naming convention feels really good.

In the immutable variants I did have to think for some time about 2 methods that change internal state of the class, but not the actual state the class provides access to. Considering they don't actually change db state, its fine to keep them in the immutable interface.

I did find a method that should not be in an immutable interface (see comment) and I have a small naming suggestion.

Great work on this.

* @param eventScopeKey the key of the event scope
* @return the next event trigger or null if none exist
*/
EventTrigger pollEventTrigger(long eventScopeKey);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be in the mutable variant of this interface, since it removes the polled event trigger from state

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch 👍


void putLatestVersionDigest(DirectBuffer processId, DirectBuffer digest);

int getNextWorkflowVersion(String bpmnProcessId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename this to nextWorkflowVersion to make it more clear that this is not a getter without a side-effect

@saig0
Copy link
Member Author

saig0 commented Feb 1, 2021

@korthout thanks for the fast review. I applied your hints. Please have a look :)

@saig0 saig0 requested a review from korthout February 1, 2021 14:17
Copy link
Member

@korthout korthout left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fast changes. LGTM 🥇

@saig0
Copy link
Member Author

saig0 commented Feb 2, 2021

bors

@saig0
Copy link
Member Author

saig0 commented Feb 2, 2021

bors r+

@ghost
Copy link

ghost commented Feb 2, 2021

Build succeeded:

@ghost ghost merged commit e3b7901 into develop Feb 2, 2021
@ghost ghost deleted the 6170-immutable-states branch February 2, 2021 09:22
This pull request was closed.
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

Successfully merging this pull request may close these issues.

Separate mutable and immutable states
3 participants