Django-storages: gs vs gcloud

Created on 10 May 2017 · 7Comments · Source: jschneier/django-storages

The old gs backend had the ability to set a querystring expiry time:

https://github.com/jschneier/django-storages/blob/master/storages/backends/gs.py

querystring_auth = setting('GS_QUERYSTRING_AUTH', True)
querystring_expire = setting('GS_QUERYSTRING_EXPIRE', 3600)

The newer (undeprecated) gcloud backend (https://github.com/jschneier/django-storages/blob/master/storages/backends/gcloud.py) does not have these settings. Before I start trying to add it: Is there a reason it's not in the new one?

google

Source

sheepeatingtaz

Most helpful comment

I'm not sure the gs backend should be deprecated right away. I have been testing with the new gcloud backend and in my experience the new one is much slower. I also found it unreliable a few times, particularly when multiple (concurrent) calls are made at the same time. Maybe the gs backend should stick around until the gcloud backend matures?

svengt on 28 May 2017

👍3

All 7 comments

svengt on 28 May 2017

👍3

There are additional features that gcloud does not support, such as gzipping files, setting object metadata (e.g. cache control) and specifying a location inside a bucket where to upload files.
All these features are available in gs.

stmos on 17 Jul 2017

Any ideas as to why the gcloud backend is unreliable? I've been noticing what @svengt observed about response times but haven't had any luck figuring out why. Originally I had been using the project in a multi-threaded environment until I realized that gcloud has been using urllib2, which isn't thread-safe. So I thought that using it in a single-threaded environment would fix my problems, but I'm now just getting very unreliable performance, unless I recreate the storage object every time I need to do something, which is very expensive.

I really want to use this project as I like being able to nicely switch between GCS in production and my file system in development.