In the version 2.0 of the servicex front end, the user could create a file servicex_query_cache.json in their home directory. This file contained a mapping between query hashs as SX request id's. The file is text and suitable for check-in to github. This was an easy way of dealing with running on different computers and not having to manually port request id's around.
The file contains a query hash to request id mapping.
Before any query was made, the file was consulted. If the query hash was present, then the matching request ID was used.
If no entry was there, then the local machine's cache was consulted, and a request id from there was used if possible.
If no request id was found, or the request id was unknown or in an error state on the backend, then a new query was run.
Once successful, the hash-request-id mapping was updated/written to the file.
If the file did not exist then it was not created.
There are alternative ways of acheiving this functionality:
Caching lookup on the server.
Request ID's become full-service items.
Somehow, however, this functionality needs to be there as it is very useful espeically for expensive transforms.
In the version 2.0 of the
servicexfront end, the user could create a fileservicex_query_cache.jsonin their home directory. This file contained a mapping between query hashs as SX request id's. The file is text and suitable for check-in to github. This was an easy way of dealing with running on different computers and not having to manually port request id's around.There are alternative ways of acheiving this functionality:
Somehow, however, this functionality needs to be there as it is very useful espeically for expensive transforms.