커스텀 스토리지 클래스를 작성하는 방법

만일 사용자 정의 파일 스토리지를 제공하고자 하는 경우 – 흔한 예로 원격 시스템에 파일을 저장할 때 – 사용자 정의 스토리지 클래스를 정의하면 됩니다. 다음 단계들을 진행해주세요.

  1. 당신의 커스텀 저장소 시스템은 django.core.files.storage.Storage의 하위 클래스여야만 합니다.

    from django.core.files.storage import Storage


class MyStorage(Storage): ...

  2. Django는 어떤 인자없이도 너의 저장 시스템을 인스턴스화 할 수 있습니다. 이는 “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. 당신의 저장 클래스는 적절한 다른 메소드와 함께 :meth:’_open()’과 :meth:’_save()’ 메소드로 구현돼야합니다. 더 많은 메소드를 아래에서 볼 수 있습니다.

    추가적으로, 만약 당신의 클래스가 로컬 파일 저장을 하면 “path()” 메소드로 오버라이드 되어야만 합니다.

  4. 너의 기억장치 클래스는:ref: ‘불변` 이여야 하는데, 이로 인해 마이그레이션내의 필드에서 기억장치 클래스가 직렬화되기 때문이다. 필드에 인수가 남아있는한:ref:’직렬가능한’, 당신은 django.utils.deconstruct.deconstructible 클래스 데커레이터를 사용할 수 있다.(이 데커레이터가 Django가 파일체계기억장치에서 사용하는 것이다)

디폴트로, 다음의 메소드는 ``NotImplementedError``를 일으키고, 일반적으로 오버라이드 되어야 합니다.

하지만 앞의 모든 메소드들이 필수적인 것은 아니며, 자율적으로 생략될 수 있다는 것을 유의하십시오. 그럴 경우에 각 메소드를 미구현 상태로 내버려 두면서도 작동하는 저장소를 만들 수 있습니다.

한 예시로, 만약 특정 콘텐츠를 지니고 있는 리스트를 백엔드에 저장하는게 고비용이 될 경우 당신은 ``Storage.listdir()``을 구현하지 않아도 된다.

다른 예시로 파일을 쓰기만 하는 백엔드가 있는 경우 당신은 위의 메소드를 구현할 필요가 없을 수 있다.

궁극적으로, 어떠한 메소드가 구현될 것인가는 당신이 정할 수 있습니다. 몇 몇의 메소드를 미구현 상태로 내버려둔다면 완전하지 않은(혹은 망가진) 인터페이스를 낳을 것입니다.

당신은 또한 커스텀 저장 객체를 위해 특별히 제작된 훅을 사용하고 싶을 것입니다. 이것들은:

_open(name, mode='rb')

필수.

Called by Storage.open(), this is the actual mechanism the storage class uses to open the file. This must return a File object, though in most cases, you’ll want to return some subclass here that implements logic specific to the backend storage system. The FileNotFoundError exception should be raised when a file doesn’t exist.

_save(name, content)

Storage.save()``으로 호출되다. "name" 은 ``get_valid_name() 과 get_available_name() 을 이미 통과했을 것이고, content 는 파일 객체 자신이 될 것이다.

Should return the actual name of the file saved (usually the name passed in, but if the storage needs to change the file name return the new name instead).

get_valid_name(name)

기본 저장 시스템에 사용할 수 있는 파일 이름을 반환합니다. 이 메서드에 전달된 “name” 호출 인자는 서버에 전송된 원래의 파일 이름이거나 “Upload_to”가 호출 가능한 경우 경로 정보가 제거된 후 해당 메서드에 의해 반환된 파일 이름입니다. 표준 문자가 아닌 문자가 안전한 파일 이름으로 변환되는 방법을 커스터마이즈하려면 이 옵션을 재정의하십시오.

“Storage”에 제공된 코드는 원래 파일 이름에서 영숫자, 마침표 및 밑줄만 유지하며 다른 모든 것을 제거한다.

get_alternative_name(file_root, file_ext)

“file_root” 및 “file_ext” 매개 변수를 기준으로 대체 파일 이름을 반환합니다. 기본적으로 확장명 앞에 밑줄과 임의의 7자 영숫자 문자열이 파일 이름에 추가됩니다.

get_available_name(name, max_length=None)

저장 메커니즘에서 사용할 수 있는 파일 이름을 반환합니다. 제공된 파일 이름을 고려할 수 있습니다. 위에서 설명한 “get_valid_name()” 방법에 따르면 이 방법에 전달된 “name” 인수는 이미 스토리지 시스템에 유효한 파일 이름으로 정리될 것입니다.

파일 이름의 길이는 제공되는 경우 “max_length”를 초과하지 않는다. 사용 가능한 고유 파일 이름을 찾을 수 없는 경우 a:exc:의심스러운 파일 작업 <django.core.exceptions.SuspiciousOperation >의 예외가 발생했습니다.

If a file with name already exists, get_alternative_name() is called to obtain an alternative name.

맞춤 스토리지 엔진 사용하기

New in Django 4.2.

The first step to using your custom storage with Django is to tell Django about the file storage backend you’ll be using. This is done using the STORAGES setting. This setting maps storage aliases, which are a way to refer to a specific storage throughout Django, to a dictionary of settings for that specific storage backend. The settings in the inner dictionaries are described fully in the STORAGES documentation.

Storages are then accessed by alias from the django.core.files.storage.storages dictionary:

from django.core.files.storage import storages

example_storage = storages["example"]
Back to Top