Fix for #278 Bug: Variables and ElementInstances not stored in DB #280
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… not stored in DB The root cause was a broken check for duplicates in the DB. This solution favors creating new ID unique index fields for the two mentioned tables, in order to feed all data (variables and element_instances) into the DB. Assuming, there are no duplicate events exported, there's no need for a duplicate check. Additionally, two indicies are added, for performance reasons. Unfortunately, because of JPA requires an @id field, a new field was introduced and there's a UPGRADE instruction documented, so people out there would be able to migrate their installations.
|
@nitram509 thank you for your contribution 🎉 Please have a look at my comment: #278 (comment) Other comments to the PR,
|
|
I will close this PR and create separate ones, as recommended. |
|
See #284 for part 1, the refactoring. |
nitram509
added a commit
to nitram509/zeebe-simple-monitor
that referenced
this pull request
Aug 9, 2021
This solution favors creating new ID, based on a composition of partitionId and position. See comments in PR camunda-community-hub#280 and Issue camunda-community-hub#278 for more details. Tests are added to show implementation works properly Unfortunately, because of JPA requires an @id field, a new field was introduced and there's an UPGRADE instruction documented, so people out there would be able to migrate their installations.
nitram509
added a commit
to nitram509/zeebe-simple-monitor
that referenced
this pull request
Aug 9, 2021
This solution favors creating new ID, based on a composition of partitionId and position. See comments in PR camunda-community-hub#280 and Issue camunda-community-hub#278 for more details. Tests are added to show implementation works properly Unfortunately, because of JPA requires an @id field, a new field was introduced and there's an UPGRADE instruction documented, so people out there would be able to migrate their installations.
nitram509
added a commit
to nitram509/zeebe-simple-monitor
that referenced
this pull request
Aug 27, 2021
This solution favors creating new ID, based on a composition of partitionId and position. See comments in PR camunda-community-hub#280 and Issue camunda-community-hub#278 for more details. Tests are added to show implementation works properly Unfortunately, because of JPA requires an @id field, a new field was introduced and there's an UPGRADE instruction documented, so people out there would be able to migrate their installations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The root cause was a broken check for duplicates in the DB.
This solution favors creating new ID unique index fields for the two mentioned tables,
in order to feed all data (variables and element_instances) into the DB.
Assuming, there are no duplicate events exported, there's no need for a duplicate check.
Additionally, two indices are added, for performance reasons.
Unfortunately, because JPA requires an @id field, a new field was introduced
and there's an UPGRADE instruction documented, so people out there would be able to migrate their installations.
In other words, this PR contains a breaking change in DB structures.
Also, if you look at what files are changed, this PR contains two commits.
The first one is pure refactoring, in order to split the ZeebeImportService class into multiple importer-classes.
This is mainly for readability. I hope you find this useful.
The second commit is the bug fix itself.
Any feedback is welcome.