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

Add "duplicateFilter" on deployment #1159

Open
berndruecker opened this issue Aug 8, 2018 · 4 comments

Comments

@berndruecker
Copy link
Member

commented Aug 8, 2018

Add some duplicate filtering like in Camunda BPM (e.g. https://docs.camunda.org/manual/7.9/user-guide/spring-framework-integration/deployment/) to allow for services to auto-deploy their owned processes at startup. Currently this leads to multiple versions being deployed or requires a manual deployment step.

@berndruecker

This comment has been minimized.

Copy link
Member Author

commented Aug 8, 2018

Should probably get easier with the current RocksDB refactoring? Would be an awesome feature to get

@jwulf

This comment has been minimized.

Copy link
Collaborator

commented May 28, 2019

At the moment this is implemented in the Node.js client library - deployWorkflow(filename, { redeploy: false }) will not deploy the workflow if it is already on the broker. This uses the listWorkflows gRPC method and compares based on the process id, so it doesn't compare the XML - only the presence or absence of a workflow with the process id.

In the current snapshot we have removed listWorkflows during the atomix refactoring so this client-side convenience will no longer work.

It is useful for programming clients that bootstrap the broker with the workflows, and it would be good to have this built-in to the broker (or keep listWorkflows available for this client-side workaround).

@menski

This comment has been minimized.

Copy link
Member

commented Jun 11, 2019

@MiguelPires

This comment has been minimized.

Copy link
Member

commented Jun 13, 2019

For documentation purposes, I'll note down some decisions (and their reasoning) that were made about this feature:

  • The filtering will check the deployed resources against their latest version and not against every version - this is more efficient and also makes it simpler in situations where the user rolls back to a previous a workflow (the "working" workflow is the always the latest)
  • Duplicate filtering will be the default behavior - this seems like a benefit for most use cases; if this becomes an issue, a parameter can be easily added later without breaking backwards compatibility
  • There will not be a parameter in the clients to toggle this feature on/off - the use cases where duplicate filtering might be problem are very specific and currently don't pose a problem; additionally, not having it makes this feature much smaller
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.