커스텀 저장 시스템 작성하기¶

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

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. 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')¶

필수.

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.

_save(name, content)¶

Called by Storage.save(). The name will already have gone through get_valid_name() and get_available_name(), and the content will be a File object itself.

Should return the actual name of 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)¶

Returns a filename suitable for use with the underlying storage system. The name argument passed to this method is either the original filename sent to the server or, if upload_to is a callable, the filename returned by that method after any path information is removed. Override this to customize how non-standard characters are converted to safe filenames.

The code provided on Storage retains only alpha-numeric characters, periods and underscores from the original filename, removing everything else.

get_alternative_name(file_root, file_ext)¶

Returns an alternative filename based on the file_root and file_ext parameters. By default, an underscore plus a random 7 character alphanumeric string is appended to the filename before the extension.

get_available_name(name, max_length=None)¶

Returns a filename that is available in the storage mechanism, possibly taking the provided filename into account. The name argument passed to this method will have already cleaned to a filename valid for the storage system, according to the get_valid_name() method described above.

The length of the filename will not exceed max_length, if provided. If a free unique filename cannot be found, a SuspiciousFileOperation exception is raised.

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