Closed andr-c closed 4 months ago
Hey @andr-c 👋
The initial intention to cache the query builder and not the response was intentional as I wanted query()
to be the equivalent of select()
, and any number of filters or modifiers can be chained to select()
. This led to false cache hits if the select()
clause was the same, but modifiers were different.
Since this approach doesn't really help in preventing unnecessary network requests, I am adding a new execute_query()
method to the connection that will cache the API response based on the query path (table name) and parameters.
@andr-c - I've a PR open for the above changes: https://github.com/SiddhantSadangi/st_supabase_connection/pull/12
Could you install it using pip install git+https://github.com/SiddhantSadangi/st_supabase_connection.git@ss/cache_api_response
and let me know if it works well for you?
Note that this version removes the query()
method and adds a new execute_query()
function that needs to be imported separately from st_supabase_connecton
: from st_supabase_connection import SupabaseConnection, execute_query
.
Usage examples have been updated in the README: https://github.com/SiddhantSadangi/st_supabase_connection/blob/ss/cache_api_response/README.md#file_cabinet-database-operations
Describe the bug It seems like setting ttl does not cache anything useful. I believe the problem is in this code:
it caches the query builder rather than an actual network response which takes place later in the execute() method of the builder.
To Reproduce Set breakpoint anywhere at httpx._client.Client.request, it's always hit despite the ttl value.
Expected behavior Network requests should not be sent for same query until the TTL expires.
** Please complete the following information: