If you need to provide custom file storage – a common example is storing files\non some remote system – you can do so by defining a custom storage class.\nYou’ll need to follow these steps:
\nYour custom storage system must be a subclass of\ndjango.core.files.storage.Storage:
from django.core.files.storage import Storage\n\nclass MyStorage(Storage):\n ...\nDjango must be able to instantiate your storage system without any arguments.\nThis means that any settings should be taken from django.conf.settings:
from django.conf import settings\nfrom django.core.files.storage import Storage\n\nclass MyStorage(Storage):\n def __init__(self, option=None):\n if not option:\n option = settings.CUSTOM_STORAGE_OPTIONS\n ...\nYour storage class must implement the _open() and _save()\nmethods, along with any other methods appropriate to your storage class. See\nbelow for more on these methods.
In addition, if your class provides local file storage, it must override\nthe path() method.
Your storage class must be deconstructible\nso it can be serialized when it’s used on a field in a migration. As long\nas your field has arguments that are themselves\nserializable, you can use the\ndjango.utils.deconstruct.deconstructible class decorator for this\n(that’s what Django uses on FileSystemStorage).
By default, the following methods raise NotImplementedError and will\ntypically have to be overridden:
Note however that not all these methods are required and may be deliberately\nomitted. As it happens, it is possible to leave each method unimplemented and\nstill have a working Storage.
\nBy way of example, if listing the contents of certain storage backends turns\nout to be expensive, you might decide not to implement Storage.listdir().
Another example would be a backend that only handles writing to files. In this\ncase, you would not need to implement any of the above methods.
\nUltimately, which of these methods are implemented is up to you. Leaving some\nmethods unimplemented will result in a partial (possibly broken) interface.
\nYou’ll also usually want to use hooks specifically designed for custom storage\nobjects. These are:
\nRequired.
\nCalled by Storage.open(), this is the actual mechanism the storage class\nuses to open the file. This must return a File object, though in most cases,\nyou’ll want to return some subclass here that implements logic specific to the\nbackend storage system.
Called by Storage.save(). The name will already have gone through\nget_valid_name() and get_available_name(), and the content will be a\nFile object itself.
Should return the actual name of name of the file saved (usually the name\npassed in, but if the storage needs to change the file name return the new name\ninstead).
Returns a filename suitable for use with the underlying storage system. The\nname argument passed to this method is either the original filename sent to\nthe server or, if upload_to is a callable, the filename returned by that\nmethod after any path information is removed. Override this to customize how\nnon-standard characters are converted to safe filenames.
The code provided on Storage retains only alpha-numeric characters, periods\nand underscores from the original filename, removing everything else.
Returns an alternative filename based on the file_root and file_ext\nparameters. By default, an underscore plus a random 7 character alphanumeric\nstring is appended to the filename before the extension.
Returns a filename that is available in the storage mechanism, possibly taking\nthe provided filename into account. The name argument passed to this method\nwill have already cleaned to a filename valid for the storage system, according\nto the get_valid_name() method described above.
The length of the filename will not exceed max_length, if provided. If a\nfree unique filename cannot be found, a SuspiciousFileOperation exception is raised.
If a file with name already exists, get_alternative_name() is called to\nobtain an alternative name.