feat: support geo_values (single geo_type) #237
Conversation
| r = fetch(['11111', '55555']) | ||
| self.assertEqual(r['message'], 'success') | ||
| self.assertEqual(r['epidata'], [counties[0]]) |
There was a problem hiding this comment.
This is probably the right choice (silently omit bogus geo values from the response) but we should revisit it when we figure out deletion encoding. One of the goals of deletion encoding is to start giving better feedback about "you asked for a bogus county" vs "that information was withheld for privacy reasons", and an error on parts of a query might have to be treated carefully.
There was a problem hiding this comment.
I think it behaves the same way for all kind of parameters that are not existing, e.g., if you specify a wrong data source you just get no results back but it doesn't throw an error. That is the current nature of just generating a where clause
| // the wildcard query should return data for all locations in `geo_type` | ||
| $condition_geo_value = 'TRUE'; | ||
| } else if (is_array($geo_values)) { | ||
| // return data for multiple location | ||
| $condition_geo_value = filter_strings('t.`geo_value`', $geo_values); | ||
| } else { | ||
| // return data for a particular location |
There was a problem hiding this comment.
If a '*' is present in the list will it be interpreted literally (matching geo_values that are '*')?
There was a problem hiding this comment.
atm. yes, there is the clear distinction see PR comment about the variants
closes #221 (single geo type only for now)
add support for
geo_values.valid variants:
geo_value=*geo_value=CAgeo_values=CA,NY