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 the lineage_mutations API handler (see /web/handlers/v2/genomics/lineage_mutations.py#L124), the response currently includes "None" values for all lineage/mutation pairs that occur at less than the cutoff frequency (a sparse response). It would be more useful to users of the Python package if instead the response was dense, containing as few "None"s as possible. This could be achieved by changing the frequency cutoff filter so that instead it removes only the mutations (columns) where no lineage matching the query is above the cutoff. Then the data which are "None" in the current response would be replaced by numeric values below the cutoff; remaining non-numeric values could be set to zero.
This should be a small change to one file, however we need to test whether it could potentially cause any issues for the front end before deploying to prod, particularly the lineage comparison tool.
The text was updated successfully, but these errors were encountered:
I think either we set these "None" value to a valid null value in JSON, or just remove that field completely from the JSON object when it's "None". It should be sufficient to exclude these hits in the response.
I think that the preferred response for outbreakpy users would be a complete table with no nulls or missing values, but we could return nulls and tell downstream users that they need to query again with a lower cutoff frequency to get this data.
In the
lineage_mutations
API handler (see /web/handlers/v2/genomics/lineage_mutations.py#L124), the response currently includes "None" values for all lineage/mutation pairs that occur at less than the cutoff frequency (a sparse response). It would be more useful to users of the Python package if instead the response was dense, containing as few "None"s as possible. This could be achieved by changing the frequency cutoff filter so that instead it removes only the mutations (columns) where no lineage matching the query is above the cutoff. Then the data which are "None" in the current response would be replaced by numeric values below the cutoff; remaining non-numeric values could be set to zero.This should be a small change to one file, however we need to test whether it could potentially cause any issues for the front end before deploying to prod, particularly the lineage comparison tool.
The text was updated successfully, but these errors were encountered: