Closed jangalinski closed 8 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.
Sounds useful. But shouldn't it be solved in the process engine?
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.
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 :)
You are right, will do!
I'll try to talk to Daniel about it tomorrow.
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.
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.
The PR has been successfully merged to 7.4 master. I consider this issue closed, I dont believe its worth to reimplement this.
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
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:
DetermineHistoryLevelCmd
is not in classpathDetermineHistoryLevelCmd
would do
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: