Escrevendo um sistema de armazenamento personalizado

Se você precisa de um armazenador de arquivos customizados – um exemplo comum é armazenar arquivos em algum sistema remoto – você pode faze-lo definido uma classe de armazenamento customizada. Você precisará seguir estes passos:

  1. O seu Sistema de armazenamento customizado deve ser uma subclasse de django.core.files.storage.Storage:

    from django.core.files.storage import Storage

class MyStorage(Storage):
    ...

  2. Django deve ser capaz de instanciar o seu sistema de armazenamento sem nenhum argumento. Isso significa que quaisquer definições devem ser tomada a partir de django.conf.settings:

    from django.conf import settings
from django.core.files.storage import Storage

class MyStorage(Storage):
    def __init__(self, option=None):
        if not option:
            option = settings.CUSTOM_STORAGE_OPTIONS
        ...

  3. A classe de armazenamento deve implementar os métodos _open() e _save(), além de qualquer outro método apropriado para a sua classe de armazenamento. Veja abaixo mais sobre estes métodos.

    Além disso, se sua classe permite armazenamento local de arquivo, deve-se sobrescrever o método path().

  4. Sua classe de armazenamento deve ser “desconstruível” para que possa ser “serializado” quando usado em um campo na “migration”. Uma vez que seus campos têm argumentos que são eles mesmos serializáveis, é possível usar o “decorator” de classe django.utils.deconstruct.deconstructible para isso (que é usado pelo Django no FileSystemStorage).

Por padrão, os seguintes métodos geram NotImplementedError e normalmente tem que ser sobrescritos.

Note porém que nem todos estes métodos são requeridos e talvez deliberadamente omitidos. Caso isso ocorra, é possível deixar cada método não implementado e ainda ter um armazenamento que funcione.

A título de exemplo, se listar o conteúdo de certas infraestruturas de armazenamento passa a ser custoso, você pode decidir não implementar o Storage.listdir.

Outro exemplo seria um backend que só lida com a escrita de arquivos. Neste caso, não seria necessário implementar qualquer um dos métodos acima.

Em última análise, quais destes métodos são implementados depende de você. Deixando de implementar alguns métodos irá resultar em uma interface parcial (possivelmente quebrada).

Você também pode querer usar hooks feitos especificamente para objetos de storage personalizados. Estes são os seguintes:

_open(name, mode='rb')

Obrigatório.

Chamado por `` Storage.open () , este é o mecanismo real que a classe de armazenamento utiliza para abrir o arquivo. Isso deve retornar um objeto `` File, embora na maioria dos casos, você vai querer retornar alguma subclasse aqui que implementa uma lógica específica para o back-end do sistema de armazenamento.

_save(name, content)

Chamado por `` Storage.save () . O `` name já terá passado por `` get_valid_name ()`` e get_available_name (), e o` content` será ele mesmo um objeto File.

Deve retornar o nome real do nome do arquivo salvo (geralmente o name passado, mas se o armazenamento precisa mudar o nome do arquivo, retorna então o novo nome).

get_valid_name(name)

Retorna um nome de arquivo adequado para uso com o sistema de armazenamento subjacente. O argumento name passado para esse método é o nome do arquivo original enviado para o servidor ou, se `` upload_to`` é um “callable” (método), o nome do arquivo retornado por esse método depois de qualquer informação de caminho ser removido. Sobrescreva isso para customizar como caracteres fora de padrão são convertidos para nomes de arquivos seguros.

Changed in Django 1.9:

Em versões antigas, este método não foi chamado quando `` upload_to`` era executado.

O código fornecido em Storage guarda apenas os caracteres alfanuméricos, pontos e “underscore” do nome do arquivo original, removendo qualquer outra cosa.

get_available_name(name, max_length=None)

Retorna um nome de arquivo que está disponível no mecanismo de armazenamento, possivelmente levando em conta o nome do arquivo fornecido. O argumento name passado para este método já terá sido limpo para um nome de arquivo válido para o sistema de armazenamento, de acordo com o método get_valid_name() descrito acima.

O comprimento do nome do arquivo não será superior a `` max_length``, se informado. Se um nome de arquivo único não pode ser encontrado, a: exc: `SuspiciousFileOperation <django.core.exceptions.SuspiciousOperation> `Exceção é gerada.

Se um name de um arquivo já existe, um “underscore” mais uma seqüência alfanumérica 7 caracteres aleatórios é anexado ao nome do arquivo antes da extensão.

Back to Top