Fix lineage for orphaned datasets #2314
Merged
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.
Signed-off-by: Michael Collado collado.mike@gmail.com
Problem
Sometimes a dataset is generated by a job whose current version no longer writes to that database. Since the lineage logic for a dataset always starts with a job that has written to or read from the dataset, we'll generate the lineage for the current version of that job, which may not include the dataset we started from.
Solution
This validates that a selected dataset node is always in the results of the lineage returned from the database. If the dataset is not in the set of nodes returned from the database, we assume that it's no longer connected to the original job and return a lineage graph with only the original dataset node.
(note that we always select the latest job that has written to or read from the dataset, so if a newer job now writes to that dataset, it will not be treated as an orphan dataset).
Checklist
CHANGELOG.md
with details about your change under the "Unreleased" section (if relevant, depending on the change, this may not be necessary).sql
database schema migration according to Flyway's naming convention (if relevant)