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

Store resolved node names in manifest #2647

Closed
jtcohen6 opened this issue Jul 24, 2020 · 1 comment · Fixed by #2837
Closed

Store resolved node names in manifest #2647

jtcohen6 opened this issue Jul 24, 2020 · 1 comment · Fixed by #2837
Labels
artifacts enhancement New feature or request good_first_issue Straightforward + self-contained changes, good for new contributors!

Comments

@jtcohen6
Copy link
Contributor

jtcohen6 commented Jul 24, 2020

Description

A neat wrinkle:

Currently, dbt doesn't store what the database form of a node should look like as a string when it runs. That means that given an existing manifest, the best we can do with the existing manifest is to tell you what the stored node would have been, if you loaded it with the current project's config - in particular, quoting.

That's probably too restrictive! Instead, we should add a field to compiled nodes that indicates what the node's "resolved name" is. I'm pretty sure this can be filled in at compile-time, with something like str(adapter.Relation.create_from(config, node)).

What does this get us?

@jtcohen6 jtcohen6 added the enhancement New feature or request label Jul 24, 2020
@jtcohen6 jtcohen6 added this to the Marian Anderson milestone Jul 24, 2020
@jtcohen6 jtcohen6 added good_first_issue Straightforward + self-contained changes, good for new contributors! and removed good_first_issue Straightforward + self-contained changes, good for new contributors! labels Aug 5, 2020
@jtcohen6 jtcohen6 modified the milestones: Marian Anderson, 0.19.0 Aug 18, 2020
@jtcohen6
Copy link
Contributor Author

Something obvious in hindsight, after playing around with #2837: relation_name is only available after a compile step, as in dbt compile, dbt docs generate, or a dbt run/dbt test of a specific model.

dbt ls doesn't include a compile step. I'll need to rethink how we'd intended to leverage this to resolve #2643. Maybe it requires a new optional argument, dbt ls --compile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
artifacts enhancement New feature or request good_first_issue Straightforward + self-contained changes, good for new contributors!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant