Handling primary vs. secondary data products WRT matches and selections #258
Description
This is less of a bug and more of a place to document something that might be an issue in the future.
Currently there are effectively two classes of data products, "primary" (currently only genome_attribs) and "secondary" (currently taxa_count and microtrait [or any other heatmap data products that use heatmap.py]). Primary data products are coded such that they assume they are always matched against first (and thus never need to run a secondary process after the user-started match process is complete) and the same for selections. Secondary data products always assume the match / selection is complete in the primary data product (and will throw an error if it's not) and then start a new process to do their own processing for a match or selection.
If we need a primary to act like a secondary or vice versa, it could be a lot of work to make that happen. It's not clear that's ever going to be an issue though...