Best way to handle caching of the validated schema?

[robswc]

Hey all!

Have been struggling with caching methods. It seems @cache_page works best, its given the fastest responses by far. The only problem is I'm unable to invalidate it.

I can manually cache with cache.set() and cache.get() - but I can't seem to be able to set the validated models. I've tried caching just the values to avoid caching a QuerySet and that seems to work alright, it is just about 20-30ms slower than the response of @cache_page

I also have some complex resolver methods as part of my Schema and those seem to break when using cached values. I've disabled them just for testing but it is another problem I run into.

So, I guess my question is mostly about how to cache the "static" response to a key and return that response without any additional processing.

Thanks!

[vitalik]

@robswc

probably you can mark your pages with some prefix

@cache_page(60 * 15, key_prefix="my_prefix") and then delete cache by that prefix (but I guess implementing delete will be different for each cache backend)

OR you just find the exact cache key for your url by calling _generate_cache_key with some mock request.url or somethng

basically your problem is that default cache_page is too smart - maybe it's easiter to do some custom cache_page function

[robswc]

Thanks for the response! I have tried this approach but found the logic for invalidating getting a bit complex. I can revisit it though and see if I can figure out the best way to handle it. Would you recommend that approach vs attempting to cache the validated models? I think the problem is if I cache something like:

{"foo": "bar"}

If I have:

@staticmethod
def resolve_foo():
...

That resolver will run and add some delay to the response time, despite it already having been "resolved." I got around this by checking what obj was being passed to the resolver but that also started getting complex. Is there a way to return a response object that won't re-validate?

Either way, I'll continue experimenting with the @cache_page approach! Thank you again for your response.