Closed noel closed 3 months ago
Thanks for the report @noel! Can you please provide more details about your specific setup that is generating this error?
I ask since, under typical operation, your projects should be hitting a project-level DbtReferenceError
during compilation before hitting a group-level DbtReferenceError
during run-time. That is to say that compilation should fail due to model being private way before the runtime fails due to a group ownership mismatch.
Additionally, it may be worth pointing out that within dbt-core groups are bounded within a project. All groups have a namespaced UniqueId
of the form group.{{project}}.{{group_name}}
, so any cross-project group checks, if they were to occur, should always fail without non-trivial modification to dbt-core.
Hey @nicholasyager! 👋
I follow what your saying I think. But can you share what the expected error would be? All that should be required is selecting from a private model in another project.
🤔 There's a good chance that I'm misinformed here. I'll do some digging in the dbt-core source and figure out what I'm missing/not up-to-date on.
Yep, I was out of date here on two(!) counts:
So, we can get this up and running by doing a similar workaround that was performed in #40: Create a function to wrap the ModelNode.from_args
class method that injects the appropriate group
value into the ModelNode
.
It's actually quite interesting that dbt-core
doesn't support this already -- it suggests to me that dbt Mesh as implemented by dbt Labs must very limited in scope: only models, with no group checking or any other access controls. Wild.
In any case, this should be a quick feature to implement.
Thanks for digging in, I had strong suspicion when I saw ModelNodeArgs
in dbt core code that the issue was clearly that they werent including group
in that data structure. Which BLEW my mind. Like it doesn't take a lot of foresight to see that might be absolutely useful to include in cross project interface. 🤦 I digress for the last time though. I am spoiled by the sqlmesh codebase these days.
Appreciate the great plugin. Thanks again.
Resolved by #60. This will go out in the next release.
Is your feature request related to a problem? Please describe. PR 40 shows better error when accessing a private or protected model of the upstream project, however, the group is missing from the message shown.
Describe the solution you'd like Ideally the group of the upstream model is shown in the error like:
Describe alternatives you've considered None
Additional context None