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

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

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. Your storage class must implement the _open() and _save() methods, along with any other methods appropriate to your storage class. See below for more on these methods.

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

4. Your storage class must be deconstructible so it can be serialized when it’s used on a field in a migration. As long as your field has arguments that are themselves serializable, you can use the django.utils.deconstruct.deconstructible class decorator for this (that’s what Django uses on FileSystemStorage).

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

• Storage.delete()

• Storage.exists()

• Storage.listdir()

• Storage.size()

• Storage.url()

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

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

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

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

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

_open(name, mode='rb')

필수.

Storage.open()``에 의해 호출되며, 스토리지 클래스가 파일을 열때 사용하는 실제 매커니즘입니다. 이 함수는 반드시 ``File 객체를 반환해야하지만, 대부분의 경우, 백엔드 스토리지 시스템에 특화된 로직을 구현한 서브클래스를 반환하는 것이 좋습니다. 파일이 존재하지 않을 경우 FileNotFoundError 예외를 발생시켜야 합니다.

_save(name, content)

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

스토리지에 저장된 파일의 실제 이름을 반환해야 합니다. (일반적으로 파일의 ``name``을 반환하지만, 스토리지가 파일명을 변경할 필요가 있는 경우 변경된 새 이름을 반환해야 합니다.)

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.

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

여러분만의 스토리지를 장고와 함께 사용하기 위한 첫번째 단계는 장고에게 여러분이 사용할 파일 스토리지 백엔드를 알려주는 것입니다. STORAGES`를 통해 알려줄 수 있습니다. 이 설정은 여러분이 사용할 스토리지의 설정값을 딕셔너리 형태로 장고의 스토리지 별칭에 매핑해주며, 이 스토리지 별칭은 장고 내에서 스토리지를 참조하기 위한 방법으로 사용됩니다. 딕셔너리의 상세한 설정값은 :setting:`STORAGES 문서에 모두 안내되어 있습니다.

스토리지들은 django.core.files.storage.storages 딕셔너리에서 별칭으로 접근할 수 있습니다.

from django.core.files.storage import storages

example_storage = storages["example"]