애플리케이션¶

애플리케이션 제작자의 경우¶

“Rock ‘n’ roll”이라는 플러그형 앱을 만드는 경우, 관리자에게 적절한 이름을 제공하는 방법은 다음과 같습니다:

# rock_n_roll/apps.py

from django.apps import AppConfig


class RockNRollConfig(AppConfig):
    name = "rock_n_roll"
    verbose_name = "Rock ’n’ roll"

``RockNRollConfig``는 INSTALLED_APPS`에 `’rock_n_roll’``이 포함되어 있을 때 자동으로 로드됩니다. 이를 방지하려면, 클래스 정의에서 :attr:`~AppConfig.default`를 ``False``로 설정하십시오.

동작이 다른 여러 가지 AppConfig 하위 클래스를 사용할 수 있습니다. 기본값으로 사용할 것이 어떤 것인지를 Django에 알리려면, 사용자가 기본이 아닌 구성을 선택하려는 경우, :setting:`INSTALLED_APPS 설정에서 ``’rock_n_roll’``을 해당 특정 클래스에 대한 점선 경로로 바꿔야 합니다.

AppConfig.name 속성은 이 구성이 적용되는 애플리케이션을 Django에 알려줍니다. AppConfig API 참조에 문서화된 다른 속성을 정의할 수 있습니다.

AppConfig 하위 클래스는 어디에서나 정의할 수 있습니다. apps.py 규칙은 설정 클래스에 대한 경로가 아닌 애플리케이션 모듈에 대한 경로를 포함할 때 Django가 자동으로 로드하도록 허용할 뿐입니다.

from django.apps import apps as django_apps

애플리케이션 사용자의 경우¶

``anthology``라는 프로젝트에서 “Rock ‘n’ roll”을 사용하고 있지만 대신 “Jazz Manouche”로 표시하고 싶다면, 다음과 같이 고유한 구성을 제공할 수 있습니다:

# anthology/apps.py

from rock_n_roll.apps import RockNRollConfig


class JazzManoucheConfig(RockNRollConfig):
    verbose_name = "Jazz Manouche"


# anthology/settings.py

INSTALLED_APPS = [
    "anthology.apps.JazzManoucheConfig",
    # ...
]

이 예제는 ``apps.py``라는 하위 모듈에 있는 프로젝트별 구성 클래스를 보여줍니다. 이것은 규칙이지 요구 사항이 아닙니다. AppConfig 하위 클래스는 어디에서나 정의할 수 있습니다.

이 상황에서, :setting:`INSTALLED_APPS`는 구성 클래스에 점선 경로를 포함해야 합니다. 왜냐하면 애플리케이션 외부에 있으므로 자동으로 감지할 수 없기 때문입니다.

구성 가능한 속성들¶

AppConfig.name¶

애플리케이션에 대한 전체 Python 경로, 예: 'django.contrib.admin'.

이 속성은 구성이 적용되는 애플리케이션을 정의합니다. 모든 AppConfig 하위 클래스에서 설정해야 합니다.

Django 프로젝트 전체에서 고유한 값이어야 합니다.

AppConfig.label¶

애플리케이션을 위한 짧은 이름, 예를 들어 “admin”

이 속성을 사용하면, 두 애플리케이션의 레이블이 충돌하는 경우 애플리케이션의 레이블을 다시 지정할 수 있습니다. 기본값은 ``name``의 마지막 구성 요소이며, 이는 유효한 파이썬 식별자여야 합니다.

Django 프로젝트 전체에서 고유한 값이어야 합니다.

AppConfig.verbose_name¶

사람이 읽을 수 있는 애플리케이션의 이름, 예를 들어 “Administration”

이 속성의 디폴트 값은 label.title() 입니다.

AppConfig.path¶

애플리케이션 디렉토리에 대한 파일 시스템 경로, 예: '/usr/lib/pythonX.Y/dist-packages/django/contrib/admin'.

대부분의 경우, Django는 이를 자동으로 감지하고 설정할 수 있지만, ~django.apps.AppConfig` 하위 클래스의 클래스 속성으로 명시적 재정의를 제공할 수도 있습니다. 몇 가지 상황에서 이것이 필요합니다. 예를 들어 앱 패키지가 여러 경로를 포함하는 `네임스페이스 패키지`_인 경우입니다.

AppConfig.default¶

이 속성을 ``False``로 설정하여 Django가 구성 클래스를 자동으로 선택하지 않도록 합니다. 이는 ``apps.py``가 하나의 AppConfig 하위 클래스만 정의하지만, Django 기본값을 원하지 않을 때 유용합니다.

이 속성을 ``True``로 설정하여 Django가 구성 클래스를 자동으로 선택하도록 합니다. 이는 ``apps.py``가 하나 이상의 AppConfig 하위 클래스를 정의하고 Django가 기본값으로 그 중 하나를 사용하기를 원할 때 유용합니다.

기본적으로, 이 속성은 설정되지 않습니다.

AppConfig.default_auto_field¶

이 앱 내의 모델에 추가할 암시적 기본 키 유형입니다. 이를 사용하여 :class:`~django.db.models.AutoField`를 써드 파티 애플리케이션의 기본 키 유형으로 유지할 수 있습니다.

기본적으로 이는 :setting:`DEFAULT_AUTO_FIELD`의 값입니다.

읽기 전용 속성¶

AppConfig.module¶

응용 프로그램의 루트 모듈, 예: <module 'django.contrib.admin' from 'django/contrib/admin/__init__.py'>.

AppConfig.models_module¶

모델을 포함하는 모듈, 예. <module 'django.contrib.admin.models' from 'django/contrib/admin/models.py'>.

애플리케이션에 models 모듈이 포함되어 있지 않으면 None 일 수 있습니다. pre_migrate 및 post_migrate`와 같은 데이터베이스 관련 신호는 ``models` 모듈이 있는 응용 프로그램에 대해서만 방출됩니다.

메소드¶

AppConfig.get_models(include_auto_created=False, include_swapped=False)¶

이 애플리케이션에 대한 클래스:~django.db.models.Model 클래스의 이터러블을 반환합니다.

앱 레지스트리가 완전히 채워져야 합니다.

AppConfig.get_model(model_name, require_ready=True)¶

주어진 ``model_name``과 함께 :class:`~django.db.models.Model`을 반환합니다. ``model_name``은 대소문자를 구분하지 않습니다.

이 애플리케이션에 해당 모델이 없으면 :exc:`LookupError`가 발생합니다.

require_ready 인자가 ``False``로 설정되지 않은 한, 앱 레지스트리가 완전히 채워져야 합니다. ``require_ready``는 apps.get_model()`에서와 똑같이 동작합니다.

AppConfig.ready()¶

서브클래스는 시그널 등록과 같은 초기화 작업을 수행하기 위해 이 메서드를 재정의할 수 있습니다. 이 메서드는 레지스트리가 완전히 채워지는 즉시 호출됩니다.

AppConfig 클래스가 정의된 모듈 수준의 모델을 import 할 수는 없지만, ready()``에서 ``import 문 또는 :meth:`~AppConfig.get_model`을 사용해 import 할 수 있습니다.

:mod:`모델 신호 <django.db.models.signals>`를 등록하는 경우, 모델 클래스 자체를 사용하는 대신 문자열 레이블로 발신자를 참조할 수 있습니다.

예제:

from django.apps import AppConfig
from django.db.models.signals import pre_save


class RockNRollConfig(AppConfig):
    # ...

    def ready(self):
        # importing model classes
        from .models import MyModel  # or...

        MyModel = self.get_model("MyModel")

        # registering signals with the model's string label
        pre_save.connect(receiver, sender="app_label.MyModel")

경고

위에서 설명한 대로 모델 클래스에 액세스할 수 있지만, ready() 구현에서 데이터베이스와 상호 작용하지 마십시오. 여기에는 (save(), delete(), 매니저 메소드 등의 쿼리 및) django.db.connection``을 통한 원시 SQL 쿼리를 실행하는 모델 메서드를 포함합니다. 모든 관리 명령을 시작하는 동안 :meth:`ready() 메서드가 실행됩니다. 예를 들어, 테스트 데이터베이스 구성이 프로덕션 설정과 분리되어 있더라도 ``manage.py test``는 여전히 프로덕션 데이터베이스에 대해 일부 쿼리를 실행합니다!

참고

일반적인 초기화 과정에서, ready 메서드는 Django에 의해 한 번만 호출됩니다. 그러나 일부 특수한 경우, 특히 설치된 응용 프로그램을 만지작거리는 테스트에서는 ready``가 두 번 이상 호출될 수 있습니다. 이 경우 idempotent 메서드를 작성하거나 ``AppConfig 클래스에 플래그를 지정하여 정확히 한 번만 실행되어야 하는 코드를 다시 실행하지 않도록 합니다.

앱으로서의 네임스페이스 패키지¶

__init__.py 파일이 없는 파이썬 패키지는 “네임스페이스 패키지”로 알려져 있으며 ``sys.path``의 여러 위치에 있는 여러 디렉토리에 분산될 수 있습니다(PEP 420 참조).

Django 애플리케이션에는 Django(구성에 따라 다름)가 템플릿, 정적 자산 등을 검색하는 단일 기본 파일 시스템 경로가 필요합니다. 따라서 네임스페이스 패키지는 다음 중 하나가 참인 경우에만 Django 애플리케이션일 수 있습니다.

1. 네임스페이스 패키지는 실제로 단일 위치만 갖습니다(즉, 둘 이상의 디렉토리에 분산되지 않음).
2. 애플리케이션을 구성하는 데 사용되는 AppConfig 클래스에는 Django가 어플리케이션을 위한 단일 기본 경로로 사용할 절대 디렉토리 경로인 path 클래스 속성이 있습니다.

이러한 조건 중 어느 것도 충족되지 않으면, Django는 :exc:`~django.core.exceptions.ImproperlyConfigured`를 발생시킵니다.

애플리케이션이 로드되는 방식¶

Django가 시작되면, :func:`django.setup()`이 애플리케이션 레지스트리를 채우는 역할을 합니다.

setup(set_prefix=True)[소스]¶

다음을 통해 Django를 구성합니다:

• 설정들을 로딩중
• 로깅 설정.
• ``set_prefix``가 True인 경우, URL 해석기 스크립트 접두어를 FORCE_SCRIPT_NAME`(정의된 경우) 또는 `/``로 설정합니다.
• 애플리케이션 레지스트리 초기화 중

이 함수는 자동으로 호출 됩니다:

• When running an HTTP server via Django’s ASGI or WSGI support.
• 관리 명령어를 실행할 때

다른 경우(예를 들어 일반 Python 스크립트)에는, 명시적으로 호출해야 합니다.

애플리케이션 레지스트리는 3단계로 초기화됩니다. 각 단계에서 Django는 설정:`INSTALLED_APPS`의 순서로 모든 애플리케이션을 처리합니다.

1. 먼저 Django는 :setting:`INSTALLED_APPS`에서 각 항목을 가져옵니다.

   애플리케이션 구성 클래스인 경우, Django는 name 속성으로 정의된 애플리케이션의 루트 패키지를 가져옵니다. Python 패키지인 경우 Django는 apps.py 하위 모듈에서 애플리케이션 구성을 찾거나 기본값 애플리케이션 구성을 만듭니다.

   이 단계에서, 코드는 어떤 모델도 가져오지 않아야 합니다!

   즉, 애플리케이션의 루트 패키지와 애플리케이션 구성 클래스를 정의하는 모듈은 모델을 간접적으로라도 가져오면 안 됩니다.

   엄밀히 말하면, Django는 애플리케이션 구성이 로드되면 모델을 가져올 수 있습니다. 그러나 :setting:’INSTALLED_APPS’ 순서에 대한 불필요한 제약을 피하기 위해 이 단계에서 모델을 가져오지 않는 것이 좋습니다.

   이 단계가 완료되면 :meth:~apps.get_app_config()’와 같은 애플리케이션 구성에서 작동하는 API를 사용할 수 있게 됩니다.

2. 그런 다음 Django는 각 애플리케이션의 models 하위 모듈(있는 경우)을 가져오려고 시도합니다.

   애플리케이션의 models.py 또는 ``models/__init__.py``에서 모든 모델을 정의하거나 가져와야 합니다. 그렇지 않으면 이 시점에서 응용 프로그램 레지스트리가 완전히 채워지지 않아 ORM이 오작동할 수 있습니다.

   이 단계가 완료되면, :meth:~apps.get_model()`과 같은 모델에서 작동하는 API를 사용할 수 있게 됩니다.

3. 마지막으로 Django는 각 애플리케이션 구성의 ready() 메서드를 실행합니다.

문제해결¶

다음은 초기화 중에 발생할 수 있는 몇 가지 일반적인 문제입니다:

• AppRegistryNotReady: 애플리케이션 구성을 가져오거나 모델 모듈이 앱 레지스트리에 의존하는 코드를 트리거할 때 발생합니다.

  예를 들어 :func:`~django.utils.translation.gettext()`는 앱 레지스트리를 사용하여 애플리케이션에서 번역 카탈로그를 조회합니다. 가져올 때 번역하려면 대신 :func:`~django.utils.translation.gettext_lazy()`가 필요합니다. (:func:`~django.utils.translation.gettext()`를 사용하면 버그가 될 수 있습니다. 활성화된 언어에 따라 각 요청 때가 아닌 가져오기 시간에 번역이 발생하기 때문입니다.)

  모델 모듈에서 가져올 때 ORM으로 데이터베이스 쿼리를 실행하면 이 예외가 트리거됩니다. ORM은 모든 모델을 사용할 수 있을 때까지 제대로 작동하지 않습니다.

  이 예외는 독립 실행형 Python 스크립트에서 django.setup() 호출을 잊은 경우에도 발생합니다.

• ImportError: can import name ... 가져오기 시퀀스가 루프에서 끝나는 경우에 발생합니다.

  이러한 문제를 제거하려면, 모델 모듈 간의 종속성을 최소화하고 가져올 때 가능한 한 적은 작업을 수행해야 합니다. 가져올 때 코드를 실행하지 않으려면, 코드를 함수로 이동하고 결과를 캐시할 수 있습니다. 결과가 처음 필요할 때 코드가 실행됩니다. 이 개념을 “게으른 평가”라고 합니다.

• django.contrib.admin``은 설치된 애플리케이션에서 ``admin 모듈의 자동 검색을 자동으로 수행합니다. 이를 방지하려면 'django.contrib.admin' 대신 ``’django.contrib.admin.apps.SimpleAdminConfig’``를 포함하도록 :setting:`INSTALLED_APPS`를 변경하십시오.