Use only 1 retrieval query for similar requests #191
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As it stands 4
QueryBuilder
queries are performed during the absolute first query of a server's lifetime.After that only 3 queries are performed.
If a filter is included and it targets a calculated OPTIMADE field stored in the Nodes' extras, another query will be added (5 then 4).
This PR drops the queries performed per request substantially to a minimum of 1 query per request.
This is done by manually subtracting
offset
from the counted results of the query when determining whether there aremore_data_available
.It also now stores the latest count and checks whether an option is supplied to the query that would alter it (
filters
,limit
,offset
). If any of these have changed since the last time count was called it will call count again.This also takes into account if there is a change, but the default value is used. E.g., if
page_offset
was not used in the original request (storing aNone
value in the server), but then it's set to0
in a subsequent request (without altering anything else about the request). This will not change the result of counting, since an offset of value0
is the default, hence equivalent toNone
.Finally, the checked extras fields are now stored. So if a filter is given which filters on an OPTIMADE field that is calculated and stored in the Nodes' extras, it will be checked (resulting in a
QueryBuilder
query) and stored in aset
. All subsequent requests that filters on the same OPTIMADE fields will not result in a newQueryBuilder
query to check whether the fields are present in all Nodes' extras (since this has already now been checked and confirmed).Note: This also means that one should restart a server after changing the served database if, e.g., new Nodes are added.