There is a defect in all 0.5.x versions of dbt-loom, in which the inclusion of non-model nodes (like seeds) will break project parsing in a downstream project. The root cause of this is that dbt-core hard-codes a model prefix to all nodes injected via ModelArgsNode, which is the only injectable type.
To work around this limitation, I've implemented a custom LoomModelArgsNode type which corrects for this hard-coded limitation.
Admittedly, I'm a little on the fence about this approach. Personally, I think that continuing to enable the inclusion of private/protected upstream models into a downstream project may have negative performance impact, and may cause user confusion if they're not aware of the project boundaries. For now, I'll preserve this inheritance, but this is something that may need to be resolved in a future minor version.
Description and motivation
There is a defect in all 0.5.x versions of dbt-loom, in which the inclusion of non-model nodes (like seeds) will break project parsing in a downstream project. The root cause of this is that dbt-core hard-codes a
modelprefix to all nodes injected viaModelArgsNode, which is the only injectable type.To work around this limitation, I've implemented a custom
LoomModelArgsNodetype which corrects for this hard-coded limitation.Admittedly, I'm a little on the fence about this approach. Personally, I think that continuing to enable the inclusion of private/protected upstream models into a downstream project may have negative performance impact, and may cause user confusion if they're not aware of the project boundaries. For now, I'll preserve this inheritance, but this is something that may need to be resolved in a future minor version.
Resolves: #52