Hi Bertrand, > On 10 Aug 2020, at 11:14, Bertrand Delacretaz <[email protected]> wrote: > > So a complete scenario could be like > > 1. Client wants to run a query with digest cf81d4 (computed according > to a definition that we publish) > 2. Client GETs /prepared/cf81d4.json and receives a 404 as the query > store is empty > 3. Client POSTs the query to /prepared and receives a 201 created > /prepared/cf81d4.json > 4. Client GETs /prepared/cf81d4.json and receives the results along > with ETag and Cache-Control headers which allow a front-end HTTP cache > to store it > 5. Later, the same or another client GETs /prepared/cf81d4.json > through the HTTP cache, which based on headers received at 4. serves > results from cache and does not touch Sling > 6. Later, the same or another client GETs /prepared/cf81d4.json, the > results caching period expired but Sling still has that query stored, > so it runs the query again and returns a new ETag > 7. If a request comes later with an expired cache and the cf81d4 query > has been purged, Sling returns a 404 and the client has to start over > a 2.
Ok. I thought you had proposed that we’d purge the query once we consider the results to be stale, but now I see what you mean. The prepared query can very well outlive the results. I think it’s a good design to rely on existing caching layers and leave the path open for application-level caching, if we’d ever need that. Thanks, Radu
