Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(ingest): conditionally include env in assertion guid #6811

Merged
merged 6 commits into from
Dec 28, 2022
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -251,14 +251,20 @@ class DBTCommonConfig(StatefulIngestionConfigBase, LineageConfig):
)
backcompat_skip_source_on_lineage_edge: bool = Field(
False,
description="Prior to version 0.8.41, lineage edges to sources were directed to the target platform node rather than the dbt source node. This contradicted the established pattern for other lineage edges to point to upstream dbt nodes. To revert lineage logic to this legacy approach, set this flag to true.",
description="[deprecated] Prior to version 0.8.41, lineage edges to sources were directed to the target platform node rather than the dbt source node. This contradicted the established pattern for other lineage edges to point to upstream dbt nodes. To revert lineage logic to this legacy approach, set this flag to true.",
)

incremental_lineage: bool = Field(
# Copied from LineageConfig, and changed the default.
default=False,
description="When enabled, emits lineage as incremental to existing lineage already in DataHub. When disabled, re-states lineage on each run.",
)
backcompat_no_env_in_assertion_guid: bool = Field(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we call this "backcompat"? This feels a bit weird. What is the case in which people would want to keep the previous behavior? In my opinion previous behavior will ALWAYS be wrong.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If someone was previously only running dbt dev ingestion (no prod), this would cause all of their assertion URNs to change.

Copy link
Collaborator Author

@hsheth2 hsheth2 Dec 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can call it legacy or something else too

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's actually probably okay. They would just need to rerun the assertions / ingestion and it would get correctly attached going forward. So the impact isn't super terrible I think...

Let's use legacy or things like this... But this is the type of config that most users should never need to see nor care about

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anshbansal we've changed it so that this is only opt-in

default=False,
description="[deprecated] Prior to version 0.9.3.4, the assertion GUIDs did not include the environment. This flag can be used to revert to the legacy behavior. "
"Note that this may cause the assertions between different envs to overwrite each other, as the GUIDs will be the same.",
hidden_from_schema=True,
)
stateful_ingestion: Optional[StatefulStaleMetadataRemovalConfig] = pydantic.Field(
default=None, description="DBT Stateful Ingestion Config."
)
Expand Down Expand Up @@ -684,6 +690,15 @@ def create_test_entity_mcps(
"platform": DBT_PLATFORM,
"name": node.dbt_name,
"instance": self.config.platform_instance,
**(
# Ideally we'd include the env unconditionally. However, we started out
# not including env in the guid, so we need to maintain backwards compatibility
# with existing PROD assertions.
{}
if self.config.env == mce_builder.DEFAULT_ENV
or self.config.backcompat_no_env_in_assertion_guid
else {"env": self.config.env}
),
}
)
)
Expand Down