introduce history level "auto"

[jangalinski]

right now, when I configure multiple spring-boot nodes to run against the same camunda db, I have to manually keep the history level in sync, otherwise starting the node will fail (history level mismatch).

Since I might not want to think about it when adding new nodes, I suggest introducing a new history level "auto". It should behave as follows:

• if the configuration is set to "auto", try to determine the configured level of the database
• if found, use this level
• if not found, fall back to default (audit)

[osteinhauer]

Sounds like a must have.

Another szenario is application environment properties and/or flyway/liquibase db migrations. At least in production environment you can use auto as history level.

Am 22.06.2015 um 21:54 schrieb Jan Galinski notifications@github.com:

right now, when I configure multiple spring-boot nodes to run against the same camunda db, I have to manually keep the history level in sync, otherwise starting the node will fail (history level mismatch).

Since I might not want to think about it when adding new nodes, I suggest introducing a new history level "auto". It should behave as follows:

if the configuration is set to "auto", try to determine the configured level of the database
if found, use this level
if not found, fall back to default (audit)
—
Reply to this email directly or view it on GitHub.

[meyerdan]

Sounds useful. But shouldn't it be solved in the process engine?

[jangalinski]

Like I said ... we will discover some issues that affect core. I would still just implement it here and then move it to core instead of linking this extension to 7.4.0.-alpha.
I already implemented this when I was still going with dropwizard: https://github.com/jangalinski/camunda-bpm-dropwizard/blob/master/core/src/main/java/org/camunda/bpm/extension/dropwizard/CamundaConfiguration.java so this shouldn't be to hard.

[meyerdan]

It's up to you of course. But it may be good to start pushing such things upstream as early as possible. This way you force us to have a look at it early on :)

[jangalinski]

You are right, will do!

[jangalinski]

See also https://app.camunda.com/jira/browse/CAM-3444

[ghost]

I'll try to talk to Daniel about it tomorrow.

[hawky-4s-]

We should create a PR for the 'auto' history level config on the platform project. Also there should be enough tests for it. Then we can include it into 7.4.

[jangalinski]

I created PR camunda/camunda-bpm-platform#165 for this. After all it seamed like a good idea to solve this in the engine directly.

[jangalinski]

The PR has been successfully merged to 7.4 master. I consider this issue closed, I dont believe its worth to reimplement this.

[jangalinski]

Christian showed that this has to be addressed, since the HistoryConfiguration keeps a list of historyLevels. So at least we have to add "auto". Problem: the fix is in the 7.4 engine core, so we won't have a solution for spring-boot and <=7.3

[osteinhauer]

To detect if the engine itself (>=7.4) provides "auto" could be determined by checking if DetermineHistoryLevelCmd is in the classpath? For <=7.3 we need starter specific configuration class(es).

Could it be simple like:

• enable if property is set to "auto" and DetermineHistoryLevelCmd is not in classpath
• order after DataSource and before ProcessEngine configuration
• execute the same statement like DetermineHistoryLevelCmd would do
• set the retrieved value in die property class so further configuration classes will use this value
• to determine if "auto" was set can be managed by the original property value