[CT-1902] [Feature] Add relation_name to the node_info dictionary

[dbeatty10]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

As described by @jtcohen6 here this feature would:

• Add relation_name (database.schema.identifier) to the node_info dictionary, which is present on all node-related logging events, and offers a convenience for looking up the most salient information. (The rest can be looked up in the manifest, using the node's unique_id.)

This would provide a mapping from relation_name → node unique_id (or vice versa). Other properties can be looked up via the node's unique_id within manifest.json.

Describe alternatives you've considered

I'm not aware of any reasonable alternatives to determine the final database.schema.identifier for a model that has been built.

For those who love a good unstructured text parsing challenge, I suppose they could try to extract this from logs/dbt.log somehow.

Who will this benefit?

There is at least one issue where a user wants to monitor logs for successful model execution and trigger another process downstream:

• [CT-1895] [Bug] Include model database in log representation or make it configurable #6712

Are you interested in contributing this feature?

No response

Anything else?

No response

[jtcohen6]

@isaac-taylor says he'd like this :) and the components, too (database, schema, alias)

[dbeatty10]

For refinement:

• When writing relation_name (and database, schema, identifier components) to the node_info dictionary, do we need to worry about case-sensitivity and/or quoted identifiers?

e.g., would we want to write out quoting also?

I'm guessing a consumer of this info will want to compare relation_name, etc for equality. I'm assuming case-sensitivity, quoting, and database-specific casing of unquoted identifiers would effect those comparisons.

[jtcohen6]

@dbeatty10 Sorry, I missed your comment before resolving this in #7304!

The approach we're taking right now:

• database, schema, alias are just the values (no quoting applied)
• relation_name will be the full string representation, which respects "include" and "quoting" policies

We could add quoting as a standalone property in the future, but I think this strikes a nice balance for now, and matches what's available in the manifest

[dbeatty10]

No worries!

Agreed that this strikes a nice balance:

relation_name will be the full string representation, which respects "include" and "quoting" policies