Caching Extensions using Django Cache #93
Conversation
|
Hey @hiporox . I can see how the validation extension being cached using django's cache would be useful, but I wonder in which scenario the parsing would would be? It seems to me that parsing should be faster than requesting an external resource for it (unless it is a very complicated query?) |
|
@bellini666 I just copied over the functionality of the two types of caches that base strawberry already supports. It is very possible that the parsing cache will just be slower. I have not tested the speed of it in comparison to a regular query lookup. I am very happy to drop that chunk of the code and just leave the validation cache |
Yeah, I think it is better to only have the validation cache here :) |
for more information, see https://pre-commit.ci
|
@bellini666 Removed the parser cache and fixed the tests. How does it look now? |
for more information, see https://pre-commit.ci
Co-authored-by: Thiago Bellini Ribeiro <hackedbellini@gmail.com>
Co-authored-by: Thiago Bellini Ribeiro <hackedbellini@gmail.com>
for more information, see https://pre-commit.ci
|
@hiporox the PR is fine, just need to make the tests pass and I'll merge it! |
for more information, see https://pre-commit.ci
|
@bellini666 Tests pass now, not sure what is up with precommit |
|
Thanks for the contribution @hiporox :) |
Implementations of Strawberry's
ParserCacheandValidationCache, but using Django's cache instead of thefunctools.lru_cacheThis is blocked by upgrading
strawberry-graphqlto>=0.98.0, since that will get us access tographql-core@3.2.0, which fixes this issue graphql-python/graphql-core#112 which stops unpicklingDocumentNode