[GOBBLIN-2137]merged dagNodeStateStore and failedDagNodeStateStore tables
Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA
- [x] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"
- https://issues.apache.org/jira/browse/GOBBLIN-2137
Description
- [x] Here are some details about my PR, including screenshots (if applicable): Right now we are maintaining two tables to maintain DagState and Failed Dag State, In this PR ,we have tried to merge FailedDagState tables into DagState by adding a column is_failed_dag in DagState
Tests
- [x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
Commits
- [x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":
- Subject is separated from body by a blank line
- Subject is limited to 50 characters
- Subject does not end with a period
- Subject uses the imperative mood ("add", not "adding")
- Body wraps at 72 characters
- Body explains "what" and "why", not "how"
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 38.80%. Comparing base (
e501b62) to head (7e3e556). Report is 9 commits behind head on master.
:exclamation: There is a different number of reports uploaded between BASE (e501b62) and HEAD (7e3e556). Click for more details.
HEAD has 1 upload less than BASE
Flag BASE (e501b62) HEAD (7e3e556) 2 1
Additional details and impacted files
@@ Coverage Diff @@
## master #4032 +/- ##
============================================
- Coverage 45.86% 38.80% -7.06%
+ Complexity 3257 1599 -1658
============================================
Files 707 388 -319
Lines 27865 15995 -11870
Branches 2796 1585 -1211
============================================
- Hits 12779 6207 -6572
+ Misses 14008 9290 -4718
+ Partials 1078 498 -580
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Should a) isFailedDag be ONLY within DagNode always, everywhere, with up-to-date value? b) isFailedDag be within DagNode, but be also in mysql table as a cache; still be always in sync with the field inside DagNode? It may make sql queries more readable.
before completing the review, i would like to understand your thoughts on this.
Should a) isFailedDag be ONLY within DagNode always, everywhere, with up-to-date value? b) isFailedDag be within DagNode, but be also in mysql table as a cache; still be always in sync with the field inside DagNode? It may make sql queries more readable.
before completing the review, i would like to understand your thoughts on this.
If we don't keep it in mysql, we may lose it in case of restarts/deployments, so we will have to store in mysql