Si necesitas proporcionar un almacenamiento de archivos personalizado -un ejemplo común es almacenar archivos en algún sistema de archivos remoto- puedes hacerlo definiendo una clase de almacenamiento personalizada. Deberás seguir estos pasos:
\nTu sistema de almacenamiento personalizado debe heredar de django.core.files.storage.Storage:
from django.core.files.storage import Storage\n\nclass MyStorage(Storage):\n ...\nDjando debe ser capaz de crear una instancia de tu sistema de almacenamiento sin pasarle argumentos. Esto significa que cualquier ajuste debe ser tomado de 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 ...\nLa clase de almacenamiento deberá implementar los métodos _open() y _save(), junto con cualquier otro método apropiado para tu clase de almacenamiento. Observar debajo más sobre estos métodos.
Adicionalmente, la clase proporciona almacenamiento local de archivos, debe redefinir el método path().
La clase de almacenamiento debe ser deconstruible para que pueda ser serializada al usarse en un campo en una migración. Siempre y cuando el campo tenga argumentos que sean serializables por sí mismos, puedes usar el decorador de clase django.utils.deconstruct.deconstructible con este propósito (es lo que Django usa en FileSystemStorage).
Por omisión, los siguientes métodos lanzan como excepción NotImplementedError por lo que deberán ser redefinidos:
\n\nNótese sin embargo que no todos estos métodos son requeridos y pueden ser omitidos. Como suele ocurrir, es posible dejar cada método sin ser implementado y tener un Storage funcional.
\nPor medio de ejemplos, si listar el contenido de cierto backend de almacenamiento se vuelve costoso, puedes decidir si implementar Storage.listdir.
\nOtro ejemplo sería un backend que solo contemple la escritura de archivos. En este caso, no necesitarías implementar ninguno de los métodos de arriba.
\nPor último, la implementación de estos métodos depende de ti. Dejar algunos sin implementar darían una interfaz parcial (posiblemente rota).
\nYou’ll also usually want to use hooks specifically designed for custom storage\nobjects. These are:
\nRequerido
\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 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, an underscore plus a random 7 character\nalphanumeric string is appended to the filename before the extension.