You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In dbt-semantic-interfaces there lives a tool called SemanticManifestValidator. The SemanticManifestValidator takes in a semantic manifest and runs a series of rules against it to ensure that it is valid. These are things like ensuring that either a measure has an agg_time_dimension set or that there is a default_agg_time_dimension set on the semantic_model that the measure belongs to.
Currently we don't run these validation rules in core. The only way someone using MetricFlow with core can run the validations is by doing
$ dbt parse
...
$ mf validate-configs
The issue with this is that validations are only run after the semantic manifest is written. This is problematic because validation issues should cause a failure before writing the semantic manifest. Additionally most people likely won't run mf validate-configs separately. Which means the issues would only be caught at query time 😬 We want to be informing customers of their issues when writing their configs, thus we need to ensure the SemanticManifestValidator is run during parsing.
Luckily, using the SemanticManifestValidator is fairly easy. It's a generic python class that requires that you declare an implementation of the SemanticManifest protocol on instantiation. It would look something like
The other part of this is presently we only construct the SemanticManifest, and specifically a PydanticSemanticManifest right before we write out the semantic manifest. We can either reuse the PydanticSemanticManifest builder to get a PydanticSemanticManifest and run that through a SemanticManifestValidator or we'll need to actually create a core implementation of the SemanticManifest protocol and then run that through a SemanticManifestValidator. The former is easier, but the latter is probably more in core's style.
Acceptance Criteria
If a manifest has semantic models and/or metrics, the SemanticManifestValidator should get run as part of parsing
It needs happen after nodes have been fully "processed" (i.e. after things like this)
It needs to happen before writing out the semantic manifest
Validation issues returned by the validation process should get logged
If there are ERROR level validation issues, parsing should be considered as having failed.
The text was updated successfully, but these errors were encountered:
github-actionsbot
changed the title
Run DSI SemanticManifest validations during pparsing
[CT-2752] Run DSI SemanticManifest validations during pparsing
Jun 27, 2023
QMalcolm
changed the title
[CT-2752] Run DSI SemanticManifest validations during pparsing
[CT-2752] Run DSI SemanticManifest validations during parsing
Jun 28, 2023
In dbt-semantic-interfaces there lives a tool called SemanticManifestValidator. The
SemanticManifestValidator
takes in a semantic manifest and runs a series of rules against it to ensure that it is valid. These are things like ensuring that either ameasure
has anagg_time_dimension
set or that there is adefault_agg_time_dimension
set on thesemantic_model
that themeasure
belongs to.Currently we don't run these validation rules in core. The only way someone using MetricFlow with core can run the validations is by doing
The issue with this is that validations are only run after the semantic manifest is written. This is problematic because validation issues should cause a failure before writing the semantic manifest. Additionally most people likely won't run
mf validate-configs
separately. Which means the issues would only be caught at query time 😬 We want to be informing customers of their issues when writing their configs, thus we need to ensure theSemanticManifestValidator
is run during parsing.Luckily, using the
SemanticManifestValidator
is fairly easy. It's a generic python class that requires that you declare an implementation of theSemanticManifest
protocol on instantiation. It would look something likeThe other part of this is presently we only construct the
SemanticManifest
, and specifically aPydanticSemanticManifest
right before we write out the semantic manifest. We can either reuse the PydanticSemanticManifest builder to get aPydanticSemanticManifest
and run that through aSemanticManifestValidator
or we'll need to actually create a core implementation of the SemanticManifest protocol and then run that through aSemanticManifestValidator
. The former is easier, but the latter is probably more in core's style.Acceptance Criteria
SemanticManifestValidator
should get run as part of parsingERROR
level validation issues, parsing should be considered as having failed.The text was updated successfully, but these errors were encountered: