-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a Way to Compare TimeDimensionSpec
s While Ignoring the Grain
#883
Conversation
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine, might want a different approach, hard to say without seeing how (or if) it'll be used more broadly.
class TimeDimensionSpecField(Enum): | ||
"""Fields of the time dimension spec. | ||
|
||
The value corresponds to the name of the field in the dataclass. This should contain all fields, but implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might consider switching to dataclasses.fields
or some other utility in the dataclasses
module for this. Depends on what we're trying to do, I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a little unclear how those would be used since those are dynamic, and I was looking for something specific I can reference in code.
spec_field_values_for_comparison: List[ | ||
Union[str, Tuple[EntityReference, ...], TimeGranularity, Optional[DatePart]] | ||
] = [self._source_spec.element_name, self._source_spec.entity_links] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be worth it to instead allow for a unique_name and type
style equality comparison for all of these spec classes? I can see this being useful for more than just time dimension specs, although right now they're the only ones that have all of these extra properties.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tlento - mind elaborating? Would those be public properties?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They don't have to be public properties. I just mean doing a comparison based on the name/type of spec. Everything else we layer into specs as properties is transient information or something we need to propagate along, like annotations about aggregation state, aliases, stuff like that.
I did just realize that you're using the entire entity links, so my original suggestion doesn't work. That said, our comparison key is currently entity link path and name for linkable specs, and I suspect would be name for everything else. Will we need other properties? If we don't have specific things we'll need to add to that comparison then maybe we just add a method that does the simple thing.
3995915
to
274d987
Compare
602ab19
to
f4c20db
Compare
f4c20db
to
86b41cc
Compare
@courtneyholcomb - I change the name of the module |
Description
This adds a key class for
TimeDimensionSpec
that can be used for comparing the specs while ignoring the grain. Useful for ambiguous group-by-item resolution where we want to match an ambiguous time dimension that the user has specified from a list of available time dimension specs.