How to invalidate the cache for a post method

[coolsnake]

I want to invalidate the cache if user call POST method to update data into database, so that th GET method can return the latest data to user.

[hard-coders]

You need to delete a key by yourself. Of course, you should use a custom key builder to get the key or delete it by using namespace.

Here's the later example.
e.g.

from redis import Redis
from fastapi import FastAPI
from fastapi_cache.decorator import cache

app = FastAPI()
redis = Redis()


@app.get("/")
@cache(namespace="some_namespace")
def get_some_data():
    return {"data": "some data from database"}


@app.post("/")
def update_some_data():
    for key in redis.keys("some_namespace:*"):
        redis.delete(key)
    return {"data": "updated data"}

If the namespace is too large, use scan_iter rather than keys function.

[coolsnake]

Thanks. But it looks we can not find key by redis.keys("some_namespace:*") without custom key builder because the key is finally hashed.

[hard-coders]

Thanks. But it looks we can not find key by redis.keys("some_namespace:*") without custom key builder because the key is finally hashed.

You are right. That's why I told you, "You should use a custom key builder". FastAPI-Cache hash keys using MD5 default, so you cannot identify resources. In general, if you don't have to invalidate immediately, set the TTL value properly.

[espdev]

This is a very common case where we need to invalidate the cache for related GET methods when updating data via POST/PUT/PATCH.

Maybe consider to add some high-level API to the library to invalidate the cache in such cases? Without having to specify a custom key builder. Since in essence the proposed method reveals internal implementation details and violates the encapsulation principle.

[vicchi]

@espdev Would you be willing to submit a PR for this?

[espdev]

@vicchi First, I need to look at the code. I think I may if I have some time on my hands.

[espdev]

It seems this PR already adds such functionality. The TagProvider approach looks flexible, but somewhat complicated. Duplicate argument names in items_provider can cause problems during refactoring. But I didn't look too deeply into the architecture of this solution.