Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Adds tag querying to listing variables
This completes #620. This implements the following behavior: Behavior is now this. Given ```python @tag( business_value=["CA", "US"] )` def combo_node(): ... @tag( business_value=["US"] )` def only_us_node(): ... @tag( business_value=["CA"], some_other_tag="BAR" )` def only_ca_node(): ... ``` then the following queries will return: ```python dr.list_available_variables(tag_filter=dict(business_lines=["CA"])) dr.list_available_variables(tag_filter=dict(business_lines="US")) dr.list_available_variables(tag_filter=dict(business_lines=["CA", "US"] )) dr.list_available_variables(tag_filter=dict(business_lines=None )) dr.list_available_variables(tag_filter=dict(business_lines="UK" )) dr.list_available_variables(tag_filter=dict(business_lines="US", some_other_tag="FOO" ) dr.list_available_variables(tag_filter=dict(business_lines="CA", some_other_tag="BAR" ) ``` So values in lists are read as OR clauses, and multiple tags in the query dict are read as AND clauses. We settled on this design since it seemed the most intuitive to read, while also leaving the door for more complex querying capabilities. Squashed commits: [f7a9752] Makes matches_query return True on empty dict [f93282b] Updates logic for tag querying This moves the tag filter logic to the node module, since it's kind of coupled to it. Behavior is now this. Given ```python @tag( business_value=["CA", "US"] )` def combo_node(): ... @tag( business_value=["US"] )` def only_us_node(): ... @tag( business_value=["CA"], some_other_tag="BAR" )` def only_ca_node(): ... ``` then the following queries will return: ```python dr.list_available_variables(tag_filter=dict(business_lines=["CA"])) dr.list_available_variables(tag_filter=dict(business_lines="US")) dr.list_available_variables(tag_filter=dict(business_lines=["CA", "US"] )) dr.list_available_variables(tag_filter=dict(business_lines=None )) dr.list_available_variables(tag_filter=dict(business_lines="UK" )) dr.list_available_variables(tag_filter=dict(business_lines="US", some_other_tag="FOO" ) dr.list_available_variables(tag_filter=dict(business_lines="CA", some_other_tag="BAR" ) ``` [94c58de] Fixing whitespace and type annotation for list_available_variables These were incorrect. [2cc83e9] Adds exposing tag_filter open on listing variables #620 This is a quick way to improve the ergonomics of listing all available variables and filtering by some criteria. ```python dr.list_available_variables() # gets all dr.list_available_variables({"TAG_NAME": "TAG_VALUE"}) # gets all matching tag name & value dr.list_available_variables({"TAG_NAME": ["TAG_VALUE", "TAG_VALUE2"]}) # gets all matching tag name & all values order invariant dr.list_available_variables({"TAG_NAME": None}) # gets all with matching tag, irrespective of value ``` This completes 620, and handles the filtering logic in the driver function. I think this is an reasonable place to put it for now. Assumptions: - if passed a list it's an exact match - AND clause across all values passed in. - None means just get me anything with that tag. - it's keyword only argument to enable us to maintain backwards compatibility for future changes. More complex clauses seem out of scope for this change. But for the future, if we want to change things, e.g. take in a query object that can express `not in, or, etc` We can do that. Another idea I didn't pursue was enabling query syntax: ```python {"TAG_NAME": "=FOO"}, # equal {"TAG_NAME": "!FOO"}, # not equal etc ``` Since with lists of values of strings, this could get quite complex to parse/understand...
- Loading branch information