커스텀 스토리지 클래스를 작성하는 방법¶
만일 사용자 정의 파일 스토리지를 제공하고자 하는 경우 – 흔한 예로 원격 시스템에 파일을 저장할 때 – 사용자 정의 스토리지 클래스를 정의하면 됩니다. 다음 단계들을 진행해주세요.
당신의 커스텀 저장소 시스템은
django.core.files.storage.Storage
의 하위 클래스여야만 합니다.from django.core.files.storage import Storage class MyStorage(Storage): ...
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 ...
당신의 저장 클래스는 적절한 다른 메소드와 함께 :meth:’_open()’과 :meth:’_save()’ 메소드로 구현돼야합니다. 더 많은 메소드를 아래에서 볼 수 있습니다.
추가적으로, 만약 당신의 클래스가 로컬 파일 저장을 하면 “path()” 메소드로 오버라이드 되어야만 합니다.
너의 기억장치 클래스는:ref: ‘불변` 이여야 하는데, 이로 인해 마이그레이션내의 필드에서 기억장치 클래스가 직렬화되기 때문이다. 필드에 인수가 남아있는한:ref:’직렬가능한’, 당신은
django.utils.deconstruct.deconstructible
클래스 데커레이터를 사용할 수 있다.(이 데커레이터가 Django가 파일체계기억장치에서 사용하는 것이다)
디폴트로, 다음의 메소드는 ``NotImplementedError``를 일으키고, 일반적으로 오버라이드 되어야 합니다.
하지만 앞의 모든 메소드들이 필수적인 것은 아니며, 자율적으로 생략될 수 있다는 것을 유의하십시오. 그럴 경우에 각 메소드를 미구현 상태로 내버려 두면서도 작동하는 저장소를 만들 수 있습니다.
한 예시로, 만약 특정 콘텐츠를 지니고 있는 리스트를 백엔드에 저장하는게 고비용이 될 경우 당신은 ``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"]