Within 0.5.1 there are two defects that can result in instability when referencing versioned models.
dbt-loom currently allows for parsing version and latest_version fields as either a string or a float. This can cause issues, since dbt-core naively injects this value into the ModelNodeArgs unique_id. If the upstream project is assuming string versions, and the downstream project defaults to float versions, the unique_id fields will not match and compilation will fail.
In 0.5.1 we are erroniously injecting references to tests. This can cause issue, since those nodes do not actually exist as models. There is an mechanism to exclude these nodes in previous versions that is failing.
To resolve these issues, I am constraining dbt-loom to only handle versions as strings. Since unique_ids are strings, this should be universally compatible. Lastly, I've updated the test-exclusion mechanism to use dbt-core's NodeType enum for continued compatibility and robustness.
Description and motivation
Within 0.5.1 there are two defects that can result in instability when referencing versioned models.
version
andlatest_version
fields as either a string or a float. This can cause issues, sincedbt-core
naively injects this value into theModelNodeArg
sunique_id
. If the upstream project is assuming string versions, and the downstream project defaults to float versions, theunique_id
fields will not match and compilation will fail.To resolve these issues, I am constraining dbt-loom to only handle versions as strings. Since unique_ids are strings, this should be universally compatible. Lastly, I've updated the test-exclusion mechanism to use dbt-core's
NodeType
enum for continued compatibility and robustness.Resolves: https://github.com/nicholasyager/dbt-loom/issues/48
Validation
Outside of updates to tests, I followed a fantastic replication playbook provided by @smilingthax to confirm the fix.