Hi Radu, On Mon, Aug 10, 2020 at 10:54 AM Radu Cotescu <[email protected]> wrote: > > On 7 Aug 2020, at 16:18, Bertrand Delacretaz <[email protected]> wrote: ... > > 5) There's no guarantee on how long the prepared queries are stored, a > > client that gets a 404 on a prepared query request must be prepared to > > use the default POST request method or store the prepared query again > > Instead of replying with a 404 and asking the client to do another POST + > GET, couldn’t we just return the > updated results with updated cache headers? > Judging by how you describe the algorithm, the Sling server would still have > to maintain a cache internally...
I wasn't planning to store the query results on the Sling side, just the query itself and enough information to be able to process conditional HTTP requests. 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. With this scenario (assuming it works, your sanity check of that is welcome) Sling just needs to store the queries, ETag and cache expiration time, which I suppose is much less than query results? -Bertrand
