Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of 'inv-by' aka cache dependencies should be done by another subsystem #416

Closed
evert opened this issue Jan 6, 2022 · 0 comments
Assignees

Comments

@evert
Copy link
Collaborator

evert commented Jan 6, 2022

Lets say we have 2 resources:

  • Resource A
  • Resource B

If resource A returns a link header like this:

Link: </resource-b>; rel="inv-by"

This lets Resource A say: "If Resource B expires, then I also expire".

This feature is currently handled by Ketting inside the 'cache middleware'. The issue with this is that it can only automatically expire resource A, if expiring resource B was done as the result of a HTTP request.

Sometimes users expire things manually or they use other systems to trigger expiries (such as websocket). Typically this is done by calling something like:

client.cache.delete('/resource-b')
// or
resourceB.clearCache();

Clearning caches that way does not trigger the cache middleware, so the cache of resource A does not get cleared for those cases.

To fix this, the 'cache dependencies' handling system needs to move somewhere else, probably the classes in src/cache

@evert evert self-assigned this Jan 6, 2022
evert added a commit that referenced this issue Jan 6, 2022
This is a fix for #416.

All tests pass, so this should not be a breaking change. The Client is
getting more and more 'cache functions'.

I would have preferred these features to exist in the `src/cache`
directory, but doing so would be a BC break so we can only introduce
this in a major version.
@evert evert closed this as completed Jan 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant