Package: django-s3-cache
This is Amazon Simple Storage Service (S3) cache backend for Django.
It is based on thedjango.core.cache.backends.filebased.FileBasedCachebackend
and operates in similar fashion. This backend usesdjango-storagesto read/write the
data into S3. It uses thes3botostorage backend.All key/values passed to this backend are stored in a flat directory structure
in your S3 bucket. It uses sha1 instead of md5 to create the file name.This project is looking for maintainers!InstallationUse pip to install from PyPI:pip install django-s3-cacheConfigure the use of this backend:CACHES = {
    'default': {
        'BACKEND': 's3cache.AmazonS3Cache',
        'OPTIONS': {
            'ACCESS_KEY' : 'Your AWS access key',
            'SECRET_KEY' : 'Your AWS secret access key',
            'BUCKET_NAME': 'Your AWS storage bucket name',
            'LOCATION'   : 'directory_prefix',
        }
    }
}Changelog1.4.3 (10 Nov 2019)switch license from BSD-3-Clause to MITSwitched to Travis-CIStarted testing with pylintInternal code refactoring and more testingConfigurationDjango S3 Cache supports many configuration options. They should be defined as
keys of theOPTIONSdictionary insettings.pyas shown above. If something
is not defined explicitly it follows the defaults ofs3botobackend fromdjango-storageswhich in turn reads them fromsettings.py.NOTE-1:some values insettings.pymay be used globally bybotoand other AWS aware
Django components since they follow the formatAWS_XXXX. It’s always best to define your
values as cache options explicitly if you don’t want to run into problems.NOTE-2:since version 1.2 Django S3 Cache is compatible with django-storages v1.1.8 which
has changed the names of configuration variables. All new variables are expected to be lower
case and the AWS keys variables changed names. For exact names see the S3BotoStorage class
definition ins3boto.py. Django S3 Cache implements backward compatibility with its previous
OPTIONS syntax to allow for easier upgrades. Older names are mapped to new ones and all
options are lower cased before passing to S3BotoStorage. The example above shows the new syntax.NOTE-3:before version 1.3 there is aCRITICAL BUGin the handling of theLOCATIONoption. If used cache objects will be stored under the defined directory, however culling
and clearing the cachewas nottaking this into account. cache.clear() or cache._cull()
willdelete the entire bucket. This has been fixed in version 1.3!NOTE-4:in versions 1.2 to 1.3 there is aBUGin the backward compatibility handling
ofOPTIONS. If you have been using the new style syntax forACCESS_KEY,SECRET_KEY,BUCKET_NAMEit would be overriden and boto will crash due to missing authentication parameters.
This has been fixed in version 1.4!Some notable options are:LOCATION- the directory prefix under which to store cache files. Defaults to empty string, which means the root directory;DEFAULT_ACL==private- default ACL for created objects. Unlike thes3botostorage backend we set this toprivate;BUCKET_ACL==DEFAULT_ACL- ACL for the bucket if auto created. By default set toprivate. It’s best to use separate bucket for cache files;REDUCED_REDUNDANCY- set toTrueif you want to save a few cents on storage costs;IS_GZIPPED- set toTrueto enable Gzip compression. Used together withGZIP_CONTENT_TYPES. Seedjango-storagesdocumentation.Django S3 implements culling strategy similar to the stock filesystem backend. It will honor the following options:MAX_ENTRIES- the maximum number of entries allowed in the cache before old values are deleted. If 0 culling is disabled. This argument defaults to 300;CULL_FREQUENCY- the fraction of entries that are culled whenMAX_ENTRIESis reached. The actual ratio is1/CULL_FREQUENCY, so setCULL_FREQUENCYto 2 to cull half of the entries whenMAX_ENTRIESis reached;ContributingSource code and issue tracker are athttps://github.com/atodorov/django-s3-cache