hmpf
commented
3 years ago This is not cached. If we were to cache it, valid-until would still lie. I cannot see that there is any technically feasible way to do this. Whenever somebody changes a plan, at a minimum modified is updated, which means if you page and filter on modified date at the same time, the results will differ.
If you filter on plans modified BEFORE a specific date, that list cannot grow, only shrink, as recently modified plans will end up not being hit by that filter.
Plans that are locked will not change. So if you filter on locked plans, that list can only grow, as more plans are locked.
We can add a cache header with an etag (expensive to calculate for the list of plans) or a last-modified date, then it is easy to know if the list of plans have changed (provided you noted the prior e-tag/last-modified date.) I'm, not sure how that would work with paging though. This still won't give you anything resembling valid-until.
Are you asking us to create a snapshot or something? Then it is a matter of how you define "valid". Yes. a snapshot won't change, but it will no longer reflect reality as soon as any plan is modified in any way.
adilhasan
Thanks for the paging! Do you plan to put an 'expiry' or 'valid until' on the result? So that the user knows they can fetch these same results up to date x? Or, you won't delete the cached results? Also, is it possible to put in a date when the query was made? Much thanks.