Add host species column to the study search panel

[valentynbez]

When searching for microbiome studies, one often must choose them from similar biological hosts. This column in the studies search page would make the search more effective and less time-consuming.

[antgonza]

@crusher083, thank you for the feedback.

In case, it helps, have you used https://github.com/biocore/redbiom? It basically has access to all the public processed data in Qiita and allows for "complex" searches.

[antgonza]

@wasade, based on your redbiom experience, do you have any suggestions about this? I think is possible to add a column to the study page with the the host_scientific_name, host_common_name, or host_taxid. What do you think?

[wasade]

That's a great idea!

…

On Mon, Oct 18, 2021, 13:16 Antonio Gonzalez ***@***.***> wrote: @wasade <https://github.com/wasade>, based on your redbiom experience, do you have any suggestions about this? I think is possible to add a column to the study page with the the host_scientific_name, host_common_name, or host_taxid. What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3091 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADTZMT5RBHFANCCZMMI5FTUHR6CXANCNFSM42WMPAEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[antgonza]

@wasade; agreed. However, do you have a suggestion of which of those 3 fields we should use?

[wasade]

Shouldnt there be a 1-1 relation with scientific name and host taxid? It may be nice to use the scientific name and allow typing into a search field but typos will be a problem. Behind the scenes the taxid will be more exact as long as it wasnt munged alot the way into a float

…

On Mon, Oct 18, 2021, 13:37 Antonio Gonzalez ***@***.***> wrote: @wasade <https://github.com/wasade>; agreed. However, do you have a suggestion of which of those 3 fields we should use? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3091 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADTZMUHT7AHW7GR3R7QHTLUHSARPANCNFSM42WMPAEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[antgonza]

Good question; yes there is a 1-1 relationship and AFAIK when we submit to EBI-ENA the server checks that the relationship is correct/valid; in other words, if the study is submitted the relationship should be valid. Thus, I guess we should go with host_scientific_name and, if speeds allows it, also add host_taxid. How does this sound? @crusher083, what do you think?

[valentynbez]

I think this kind of filtering would improve research a lot, as researchers are mostly concentrated around one host species.
Host_scientific_name would be better of course, but I am aware of possible software limitations.

[antgonza]

Just a quick update about this.

1. As first step to allow this, we have to improve the speed of the study listing loading by improving the SQL, which didn't work, or removing the "non" important/used parts, which actually worked nicely. Just FYI, the main way to test this is loading the admin study listing, which before used to take 20.4 s ± 276 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) and now it takes 2.02 s ± 6.57 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
2. Then we can start adding new things and see how long it will take. In this PR we can actually add the new information; however, I don't think is worth uncommenting those sections because this new functionality will raise the time to: 7.48 s ± 343 ms for admins and even worst it will raise the public listing from 760 ms ± 4.4 ms to 3.4 s ± 137 ms.

IMOO the correct implementation (which will not be ready for the next deployment) should create a new table with the columns we want to display and add a rule so this new table gets populated when there is an insert or update to the tables.