2013-08-06 4 views
3

views.py에 다른보기에 동일한 장고 ContentTypes를 검색하는보다 효율적인 방법은 무엇의 견해?모범 사례는

a), 개별적으로 각 뷰 타입 검색과 같이 그래서 같이

from django.contrib.contenttypes.models import ContentType 

def my_view1(request): 
    t1 = ContentType.objects.get_for_model(my_model1) 
    t2 = ContentType.objects.get_for_model(my_model2) 
    # ... work with t1 and t2 


def my_view2(request): 
    t1 = ContentType.objects.get_for_model(my_model1) 
    t2 = ContentType.objects.get_for_model(my_model2) 
    # ... work with t1 and t2 

또는 b) 사용 된 형식을 가져 번 views.py의 시작에서 상수로 :

from django.contrib.contenttypes.models import ContentType 

T1 = ContentType.objects.get_for_model(my_model1) 
T2 = ContentType.objects.get_for_model(my_model2) 

def my_view1(request): 
    # ... work with T1 and T2 


def my_view2(request): 
    # ... work with T1 and T2 

ContentTypes 데이터베이스 테이블은 실제로 작지만 Django는 여전히 각 쿼리에 대한 연결을 만들어야합니다. 그래서 내 추측은 b)가 더 빨라 ...?! 주석 행에서

답변

5

(source code) get_for_model에 : 필요한 경우

가의 ContentType를 작성, 해당 모델에 대한 ContentType이 오브젝트를 돌려줍니다. 동일한 모델에 대한 후속 조회가 데이터베이스에 적용되지 않도록 조회가 캐시됩니다.

결과가 캐시되므로 각보기에서 유형을 따로 검색 할 수 있습니다.

그러나보기에서 코드를 복제하는 대신 단일 함수 또는 모델 메서드를 작성할 가능성을 고려하십시오.

+0

캐시가 뷰 외부에 유지된다고 가정하면 완벽 할 것입니다. 그래서 문제는 :이 캐시가 전역인지 또는 일반 Django 쿼리 세트와 같은 것인가? 하나의 뷰의 런타임으로 제한됩니까? –

+0

질문의 b) 옵션과 같습니다. 캐시는 동일한 작업자/서버 프로세스를 사용하는 모든 요청간에 공유됩니다. 예를 들어, Gunicorn에서 Django를 실행하고 9 명의 작업자를 시작하면 각 작업자는 고유 한 ContentType 캐시를 갖게됩니다. –