Add semantic_model_origin property to LinkableElement interface #1230
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 23, 2024
|
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
1 similar comment
|
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
tlento
force-pushed
the
add-element-type-to-linkable-element-interface
branch
from
ee88ff9 to
2ec263f
Compare
Base automatically changed from
add-element-type-to-linkable-element-interface
to
main
May 24, 2024 01:09
tlento
force-pushed
the
add-semantic-model-origin-to-linkable-element-interface
branch
2 times, most recently
from
506ca50 to
7b8a6b8
Compare
tlento
force-pushed
the
add-semantic-model-origin-to-linkable-element-interface
branch
from
7b8a6b8 to
2e4a1e1
Compare
This was referenced Jun 12, 2024
LinkableElements have a commonality, which is that they always have either a semantic model where they are defined, or they are virtual constructs (either metric queries or virtual dimensions, such as metric_time). In order to do predicate pushdown evaluation against source nodes, we require the linkable element to have a singular semantic model origin. That may be a virtual model, as in the case of metric_time or metric elements, or it may be a concrete model, as in the case of all other entities and dimensions. This change provides that accessor. It is separated out for ease of review due to the need to rename the existing `semantic_model_origin` property. We could not re-use it, as dataclasses do not allow a mixture of @Property decorated functions and simple properties. This has the added benefit of differentiating between the semantic model origin, which may be virtual, and the semantic model containing the element definition.
tlento
force-pushed
the
add-semantic-model-origin-to-linkable-element-interface
branch
from
2e4a1e1 to
2ea0703
Compare
This was referenced Jun 25, 2024
tlento
deleted the
add-semantic-model-origin-to-linkable-element-interface
branch
This was referenced Jun 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LinkableElements have a commonality, which is that they always have
either a semantic model where they are defined, or they are virtual
constructs (either metric queries or virtual dimensions, such as
metric_time).
In order to do predicate pushdown evaluation against source nodes,
we require the linkable element to have a singular semantic model origin.
That may be a virtual model, as in the case of metric_time or metric
elements, or it may be a concrete model, as in the case of all other
entities and dimensions.
This change provides that accessor. It is separated out for ease of
review due to the need to rename the existing
semantic_model_originproperty. We could not re-use it, as dataclasses do not allow a mixture
of @Property decorated functions and simple properties. This has the
added benefit of differentiating between the semantic model origin,
which may be virtual, and the semantic model containing the element
definition.