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

Use core django for caching signed urls. #13

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

scattym
Copy link

@scattym scattym commented Mar 30, 2018

Use the caching feature of django core to cache urls. Using this
feature we can create multi-day urls and keep them cached in
whatever caching backend is configured. May only help in certain
use cases, but one of those use cases is mine :)

scattym added 2 commits March 30, 2018 20:47
Use the caching feature of django core to cache urls. Using this
feature we can create multi-day urls and keep them cached in
whatever caching backend is configured. May only help in certain
use cases, but one of those use cases is mine :)
Just in case it's not throwing an exception.
@strayer
Copy link
Owner

strayer commented Mar 30, 2018 via email

Copy link
Owner

@strayer strayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @scattym,

sorry for taking so long… thanks again for the PR!

The code itself looks fine, but this really needs tests. I think there should be at least three tests:

test_should_cache_urls_when_enabled

Basically check wether a second call returns the identical URL. This may generate false positives if the gcloud API itself generates an identical URL, but I this would come up with the other test.

test_should_not_cache_urls_by_default

As before, but simply checking a second call returns a different URL.

test_should_not_return_cached_urls_when_cache_disabled

This is a little more complicated. This should test that a different URL is returned when caching is disabled but this cache_key does have an entry in the cache.

For reference: Changing settings within a test is already done here: https://github.com/Strayer/django-gcloud-storage/blob/db78650/tests/test_class.py#L256-L258

I don't think testing cache expiry and such is required, that should be handled by Djangos core tests already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants