[SPIKE] [CT-2669] Revisit NodeRelation

[peterallenwebb]

Several concerns have been raised about the NodeRelation class, which is currently part of the semantic interfaces protocol for SemanticModel. See this comment for the full discussion, but the core issues are:

• Should the NodeRelation just be replaced with a single string representing the fully qualified and appropriately quoted relation name? Otherwise should it be combined somehow with the existing StateRelation class?
• How will we coordinate these changes with changes to the dbt-semantic-interfaces? This is an interesting early test case for changes that need coordination between it and dbt-core.

[jtcohen6]

Should the NodeRelation just be replaced with a single string representing the fully qualified and appropriately quoted relation name?

Not either/or, but yes/and! We should include both the three components (database, schema, identifier) and the stringified/quoted relation_name. Similar to what we do for logging (although there we do call it alias instead of identifier).

dbt-core/core/dbt/events/types.proto

Lines 29 to 35 in 6f51de4

	// NodeRelation
	message NodeRelation {
	string database = 10;
	string schema = 11;
	string alias = 12;
	string relation_name = 13;
	}

Otherwise should it be combined somehow with the existing StateRelation class?

I agree there's some significant overlap between these, and they would ideally be consistent!

[jtcohen6]

@peterallenwebb What's the latest state of this conversation with the MetricFlow / DSI team? My sense is that's what's blocking us from making this change, not any actual complexity of the change within dbt-core

[peterallenwebb]

@jtcohen6 Sorry for the late update, but we went over final release strategy with the MetricFlow team and we plan to get this change into Core, along with a coordinated change in dbt-semantic-interfaces late today or early tomorrow.

[peterallenwebb]

We decided against any changes here. It would have been nice to rename the schema_name property on NodeRelation to schema, for greater consistency in the manifest JSON, but Pydantic reserves the field name schema which would have complicated the changes in dsi-semantic-interfaces considerably. The benefits outweigh the costs.