The time necessary to complete a BTE query is highly variable. Long query times could be driven by throttling the dispatching of API calls to avoid overloading servers, by increasingly lengthy query paths, and by the addition of compute-heavy APIs to the distributed-KG. Here, we will implement the ability to utilize cached results from previous BTE queries. This will be useful in many situations, including when applying new node or edge filters, when modifying or extending existing queries, or when reinitiating failed queries due to API outages.
As one potential implementation, we may follow the pattern we used in the python client for mygene.info and myvariant.info, which uses a local sqlite database.
The time necessary to complete a BTE query is highly variable. Long query times could be driven by throttling the dispatching of API calls to avoid overloading servers, by increasingly lengthy query paths, and by the addition of compute-heavy APIs to the distributed-KG. Here, we will implement the ability to utilize cached results from previous BTE queries. This will be useful in many situations, including when applying new node or edge filters, when modifying or extending existing queries, or when reinitiating failed queries due to API outages.
As one potential implementation, we may follow the pattern we used in the python client for mygene.info and myvariant.info, which uses a local sqlite database.