Skip to content

Maintain secondary indices of keys? #104

@dgilmanAIDENTIFIED

Description

@dgilmanAIDENTIFIED

Our use case is that we have a complex get() function signature and a custom key() to get a sensible cache key out of it. We'd like to also be able to delete keys in bulk along secondary indices. For example, the Django user could be a secondary index, and we'd want to be able to wipe all cache keys for a given user. But it probably wouldn't be too tricky to make it generic as well: e.g. a secondary index on the user id, but also some user category, or a broad category of "everything" if you wanted to purge all keys maintained by cacheback.

What do you think about an API like so:

Job(secondary_indices=[user.id, user.favorite_color, 'all_users']).get(a, b, ...)

(then, later, when it is time to invalidate)

Job().delete_on_index(user.id)  # drop for this user
Job().delete_on_index("red")  # drop for users with favorite color red
Job().delete_on_index("all_users")

The Django cache API doesn't have an atomic way to maintain the list of cached keys. A generic implementation will be racy, but if you're open to allowing specialization for cache backends you could have custom implementations that use the client in a smarter way.

I can't promise I'll have the availability to do this implementation but interested in your feedback. I know you have process_result, but maybe there's an argument here to make it available in the base class? You'd still have to compute your key() a second time if you did it in process_result or extend its function signature. (Or maybe Call could store the key too?)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions