Open mccalluc opened 3 years ago
@mccalluc This issue doesn't come up in with proteins. The sequencing data types we have are very sparse, but the proteomics data types we have are very dense.
Right now, this data isn't stored in the index, but my idea would be to have client.select_genes().get_list() return something of the form [{"gene_symbol":"VIM", "num_cells":5000, "num_datasets":7}] or similar. Do you think you could work with that?
@SFD5311 : Seems good to me. Is num_*
a convention that's already established in the API? Does it make sense to put it all at the top-level, or would a nested structure be more flexible over time?
These are small design questions: Just use your best judgement.
That convention is not yet established, because we don't really store this type of data explicitly anywhere else. I do like the idea of the nested structure, so I'll probably run with that, and follow up here once the server side work is done.
We're still waiting on back-end support, so I'm going to move this to backlog.
Update from Sean:
Yes, thanks for resurfacing. Will also have to wait for the next index version, but should be doable then.
(John will ask Sean if available.)
Let me know if you need a mockup, but remove strikethrough text and turn the text into the grayed-out/unselectable text (the whole line's text should be grayed out including the 'insufficient data' part).
There are a number of genes (and proteins?) where the user just won't find any results. In the type-head, we should should that we know it exists in the world... but that we don't have data. Something like:
in
routes_cells.py
:and