search

camunda / camunda-bpm-spring-boot-starter

Camunda BPM bootified!
Apache License 2.0
325 stars 161 forks source link

introduce history level "auto" #8

Closed jangalinski closed 8 years ago

jangalinski commented 9 years ago

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:

osteinhauer commented 9 years ago

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 commented 9 years ago

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

jangalinski commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

You are right, will do!

jangalinski commented 9 years ago

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

ghost commented 9 years ago

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

hawky-4s- commented 9 years ago

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 commented 9 years ago

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

jangalinski commented 9 years ago

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

jangalinski commented 8 years ago

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 commented 8 years ago

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: