[CT-3204] [implementation] Automate creation of metricflow_time_spine if the project defines semantic objects

[graciegoheen]

Housekeeping

• [X] I am a maintainer of dbt-core

Short description

From https://github.com/dbt-labs/dbt-core/issues/8319

Currently, if the user defines semantic objects in their project, but not a model named metricflow_time_spine, we raise an error.

We should simply create the model automatically, if it is not found in the project, using the recommended definition.

Users should still have the ability to create themselves with a custom implementation if they so choose.

Acceptance criteria

• if the user defines semantic objects in their project, but not a model named metricflow_time_spine, we should create the model automatically using the recommended definition
• users should still have the ability to create themselves with a custom implementation if they so choose.

Impact to Other Teams

semantic layer

Will backports be required?

no

Context

So there are two main concerns I believe:

Squaring partial parsing with generating a metricflow_time_spine model when one isn't specified Auto-generating the metricflow_time_spine correctly given the any adapter For Issue (1) there are four possible states

a. metricflow_time_spine was specified by the user and that's still the case b. metricflow_time_spine was specified by the user and now isn't (and thus should be generated) c. metricflow_time_spine wasn't specified by the user (and thus generated) and that's still the case d. metricflow_time_spine wasn't specified by the user (and thus generated) but now it is specified by the user

I think the solution is at the end of parsing if there are semantic layer nodes and no metricflow_time_spine model we add one and mark it as auto generated. At the start of parsing if there is a saved manifest, we drop the metricflow_time_spine node if is marked as having been auto generated. This workflow makes the following happen in the corresponding cases.

a. the metricflow_time_spine is handled by the user specification b. the user specifed metricflow_time_spine gets dropped during partial parsing, and then re-added via the auto-generation c. the auto generated metricflow_time_spine gets dropped, and then re-added at the end d. the auto generated metricflow_time_spine gets dropped, and then the user specified metricflow_time_spine gets added

For issue (2) I don't think we need a cross-database macro for date types, though it would be nice. Instead we could just use the same jinja template we use for the date_spine macro tests, were we do different calls to the macro based on the target data warehouse.