Django가 임시 데이터를 전송하는 방법에 대한 자세한 설명

최근에 사용한 임시 데이터 전송을 요약하자면

세 가지 방법이 있습니다. cookie,session,cache

먼저 쿠키 선택 방법을 알려드리겠습니다. 쿠키를 사용하지 않는다는 점만 이해하면 됩니다. 사용자 쿠키가 꺼지고 HttpResponse와 함께 전달되어야 하기 때문입니다.

구성 시 쿠키 사용을 선택하지 말고 시스템 기본 데이터베이스를 따르십시오.

캐시 메모리에서는 사용이 편리하고 간편하지만 메모리만 차지합니다.... 라이브러리에 넣어두는 것도 가능합니다

다음은 이 세 가지 방법의 구성 및 사용입니다

One: cookie

• Get cookie

HttpRequest.COOKIES

표준 사전 반환

모든 쿠키를 포함하며 키 값은 str입니다

• 저장 쿠키

HttpResponse.설정_cookie(key, value='', max_age=None,expires=None, path='/', domain=None, secure=None, httponly =False)

max_age가 초 단위로 설정되고 저장됩니다. 기간이 None인 경우 기간은 클라이언트

도메인과 동기화됩니다. 크로스 도메인 쿠키 설정

domain=".lawrence.com"은 www.lawrence.com, 블로그 .lawrence.com과 캘린더s.lawrence.com 모두에서 읽을 수 있는 쿠키를 설정합니다. 그렇지 않으면 쿠키는 다음과 같습니다.

은 domian=[]으로 쓸 수 있습니다. 오류는 보고되지 않지만 실제로 크로스 사이트가 가능한지 테스트는 없습니다.

httponly= False True로 설정하면 클라이언트의 js가 쿠키를 읽는 것을 방지합니다

• 삭제 작업

delete _cookie(key, path='/', domain=None)

key로 지정한 쿠키를 삭제합니다. 이 경우 쿠키가 없으면 아무 일도 일어나지 않습니다.

set_cookie가 경로를 지정하는 경우 일관되게 삭제해야 합니다. 그렇지 않으면 삭제되지 않습니다

• 기타 콘텐츠

표준 사전이므로 요청하세요. .COOKIES['key']='value' 내용을 쿠키에 넣을 수도 있지만 다음 뷰로 전달되면 값이 손실됩니다.

하나의 뷰에 설정된 쿠키를 사용하기 전에 다음 보기로 전달됩니다:

view1:
　　res = HttpResponseRedirect(revers("namespace:name")
　　res.set_cookie('key_set', 'value_set_view1', 60)
　　# 在这里是没办法获取不到现在的这个cookie
　　print(request.COOKIES)
　　# 直接设置COOKIES
　　COOKIES['key_dict'] = 'values_dict'
　　# 这里可以看到上面设置的内容
　　print(request.COOKIES)
　　return res
　　view2: 假设上面的Response就是指向这里的
　　print(request.COOKIES)
　　# 这里可以看到上面通过set设置的 key_set ,但是通过字典设置的key_dict就没有了

2: 세션 사용

미들웨어 플러그인 세트에 django.contrib.sessions를 추가합니다. .middleware.SessionMiddleware

django1.10은 MIDDLEWARE이고, 1.08은 MIDDLEWARE_CLASSES

이며 INSTALLED_APPS에 'django.contrib.sessions'가 있어야 합니다.

세션을 설정할 수 있습니다. 쿠키, 파일, 메모리, 데이터베이스 기반으로

• 데이터베이스 기반으로 INSTALLED_APPS에 'django.contrib.sessions' 추가

구성이 완료되면 Manage.py migration

• 을 실행하여 파일을 기준으로 SESSION_ENGINE을 "django.contrib.sessions.backends.file"로 설정합니다.

동시에 SESSION_FILE_PATH를 설정하여 파일 저장 위치를 ​​지정할 수 있습니다. 그렇지 않으면 수정하지 않은 경우 시스템 기본값을 사용합니다.

• 쿠키 기반 세션, 고객이 쿠키를 사용하지 않도록 설정할 수 있으므로 권장하지 않음

SESSION_ENGINE을 "django.contrib.sessions.backends.signed_cookies"로 설정

• 캐시 기준으로 캐시를 설정하고 캐시 저장 위치를 ​​메모리로 설정한 경우 세션을 캐시 기반으로 설정할 수 있는 것을 권장합니다. 캐시가 백엔드로 Memcached를 사용하는 경우에만

그렇지 않으면 캐시를 직접 사용하는 것이 더 유연하고 로드가 적습니다

SESSION_ENGINE은 settings.py의 가장 바깥쪽 레이어에서 직접 설정할 수 있습니다

setting.py

SESSION_ENGINE = "django.contrib.sessions.backends.file"

• 세션 사용

세션 기본 클래스

backends.base.SessionBase

세션 보기

request.session 표준 클래스 사전 가져오기

방법도 사전과 동일합니다(개인 메서드 사용하지 마세요)

session['fav_color'] = 'blue' 세션 설정

get(key, default=None)

예: fav_color = request.session.get('fav_color', 'red')

pop(key)는 키를 삭제합니다. -value 쌍을 이루고 값을 반환합니다

예: fav_color = request.session.pop('fav_color')

keys()

items()

setdefault(key[,default=None]) 키가 있으면 해당 값을 반환하고, 없으면 키-값 쌍을 설정합니다. 사전에 추가하고 기본값을 반환합니다

clear ()

특수 방법

flush()

현재 세션 데이터를 삭제하고 세션의 쿠키를 삭제합니다. 이 작업은 사용자가 로그아웃할 때

set_expiry(value)를 사용하여 세션 시간 초과 길이를 설정할 수 있습니다.

값은 양수 정수, datatime/ timedelta,0,None

정수(초) n초 동안 아무런 작업도 수행하지 않으면 만료됩니다.

datatime/timedelta 이 시점에 만료됩니다.

0 브라우저 종료 시 만료

None 전역 기본값과 동일

get_expiry_age() 세션이 만료될 때까지의 시간 또는 만료 정보를 반환합니다. 사용자 정의되지 않았습니다

키워드 매개변수

수정: 세션의 마지막 수정 시간, 기본값은 현재 값입니다. 만료 기간을 결정하기 위해 이전 또는 이후의 값을 전달할 수 있습니다. 🎜>

expory 사용자 정의 만료 정보

get_expiry_

date

() 만료 날짜를 반환하고, 만료 또는 uncustomized는 쿠키 저장 시간을 반환 get_expire_at_browser_close()

사용자의 브라우저가 닫힐 때 사용자의 세션 쿠키에 따라 True 또는 False를 반환합니다. 만료되나요?

clear_expired() 클래스 메소드 세션 저장소에서 만료된 세션을 지웁니다.

cycle_key()는 현재 세션 데이터를 유지하면서 새 세션을 생성합니다.

3: 캐시 사용

캐시 설정(메모리가 충분하고 필요할 때 내장된 백그라운드를 사용하여 Memcached 구성)
파일의 캐시

CACHES = {

'기본값': {

'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache ',

'LOCATION': '/var/tmp/django_cache', # win에서 'c:/tmp/django_cache'로 변경된 경우 파일 경로

}

}

경로는 현재 사용자의 42(읽기 및 쓰기) 권한이 필요한 디렉터리인 절대 경로입니다.

데이터베이스에 캐시됨

CACHES = {

'기본값': {

'BACKEND': 'django.core.cache.backends.db.DatabaseCache',

'LOCATION': 'my_cache_table', #Table 이름, 법적, 사용되지 않음

}

}

python Manage.py createcachetable 캐시 테이블을 생성합니다. 테이블 이름은 LOCATION

메모리 내 캐시(기본값)

CACHES = {

'기본값': {

'BACKEND': 'django.core.cache.backends.locmem.LocMemCache' ,

'LOCATION': 'unique-snowflake', # 메모리가 여러 개인 경우에만 메모리를 구성하면 됩니다.

}

}

가상 캐시: 캐시하지 않지만

인터페이스

를 유지하여 개발 및 프로덕션 환경의 일관성을 보장합니다.

캐시 = {

'기본값': {

'백엔드': 'django.core.cache.backends.dummy.DummyCache',

}

}

CACHES 매개변수 설정

• TIMEOUT 기본 시간 제한은
300

으로 5분입니다

VERSION 기본 캐시 버전 번호

OPTIONS: 이 매개변수는 캐시 백엔드에 전달되어야 합니다. 유효한 옵션 목록은 캐시 백엔드에 따라 다르며, 타사 라이브러리에서 지원하는 캐시는 이러한 옵션을 기본 캐시 라이브러리에 직접 구성합니다.

캐시 백엔드는 자체 선택 전략(파일, 데이터베이스, 메모리)을 구현하고 다음 옵션을 구현합니다.

MAX_ENTRIES: 이 값을 초과하는 경우 캐시에 허용되는 최대 항목 수입니다. 이 매개변수의 기본값은 300입니다.

CULL_FREQUENCY: MAX_ENTRIES에 도달할 때 삭제되는 항목의 비율입니다. 실제 비율은 1 / CULL_FREQUENCY이므로 CULL_FREQUENCY를 2로 설정하면 MAX_ENTRIES에 설정된 값에 도달할 때 캐시의 절반이 삭제됩니다. 이 매개변수는 정수여야 하며 기본값은 3입니다.

CULL_FREQUENCY 값을 0으로 설정하면 MAX_ENTRIES에 도달하면 캐시가 지워집니다. 일부 캐시 백엔드(특히 데이터베이스)의 경우 캐시 누락이 많이 발생합니다.

예:

은 메모리에 캐시되며 시간 초과는 60*10 600초, 500개 항목입니다. 캐시되어 있으며 매번 1/5 삭제

CACHES = {

'default': {

'BACKEND': 'django.core.cache.backends.locmem. LocMemCache' ,

'TIMEOUT': 600,

'OPTIONS': {

'MAX_ENTRIES': 500,

'CULL_FREQ UENCY': 5

} }

}

}

• 캐시 전략: 전체 사이트 캐시, 뷰 캐시, 템플릿 조각 캐시

• 전체 사이트 캐시:

setting.py

1.08

MIDDLEWARE_CLASSES = (

'django.middleware.cache.UpdateCacheMiddleware',

'django.middleware.common.CommonMiddleware',

'django.middleware.cache.FetchFromCacheMiddleware',

)

1.10

MIDDLEWARE = ​​​​[

'django.middleware.cache.UpdateCacheMiddleware',

'django.middleware.common.CommonMiddleware',

'django.middleware.cache.FetchFromCacheMiddleware',

]

잘못된 순서에 주의하세요

그런 다음 settings.py의 가장 바깥쪽 레이어에 값을 추가하세요

CACHE_MIDDLEWARE_ALIAS - 저장된 캐시의 별칭 , 설정하지 않으면 '기본값'이 됩니다. '

CACHE_MIDDLEWARE_SECONDS – 각 페이지를 캐시해야 하는 시간(초).

CACHE_MIDDLEWARE_KEY_PREFIX – 동일한 Django를 사용하는 여러 웹사이트에서 캐시를 공유하는 경우 installation이면 이 값을 현재 웹사이트 이름이나 키 충돌을 피하기 위해 이 Django 인스턴스를 나타내는 다른 고유한 문자열 으로 설정하세요. 상관하지 않으면 빈 문자열로 설정할 수 있습니다.

단일 보기 캐시

from django.views. decorators.cache import cash_page

@cache_page(60 * 15)

def my_view(요청):

통과

여러 URL이 동일한 보기를 가리키며 각 URL은 다음과 같이 별도로 캐시됩니다.

url(r'^foo/([0-9] { 1,2})/$', my_view),

foo/12

foo/13은 서로 다른 캐시를 사용하지만 두 12는 모두 동일한

@cache_page( 60 * 15, 캐시="special_cache")

예: 지정된 캐시만 사용됩니다

CACHES = {

'기본값': {

'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',

'TIMEOUT': 600,

'OPTIONS': {

' Max_Entries': 500,

'Cull_주파수': 5

}

},

'Special_cache': {

'TIMEOUT': 600,

'OPTIONS': {

'MAX_ENTRIES': 500 >When /cache/ 및 /nocache/에 액세스해야 합니다. 두 페이지도 동일한 페이지를 가리키지만 하나는 캐시되고 다른 하나는 캐시되지 않습니다.

캐시할 페이지를 URL이 아닌 URL에 지정할 수 있습니다. 보기

url(r'^cache/$', 캐시_페이지(60 * 15)(my_view), name='cache'),

url(r'^nocache/$', my_view, name='nocache' ),

템플릿 캐시

{% 로드 캐시 %}

{% 캐시 기간(초) 이름%}

{% endcache name%}

캐시를 더욱 유연하게 사용

뷰에서 django.core.cache 캐시 가져오기

cad = 캐시['default'] # 여기의 이름은 CACHES와 동일합니다. 구성은 동일합니다

cas = 캐시['special_cache']

일반적으로 사용되는 방법

cad.set('key' ,'value',duration) 기간이 설정되지 않으면 기본값 또는 사용자 정의 값이 사용됩니다.

cad.get('key') 키가 없으면 None을 반환합니다. 기본값 get('key','default value')을 지정할 수도 있습니다. 키가 없으면 '

cad.add('key','value'를 반환합니다. ) 키가 없으면 키-값을 추가합니다. 키가 이미 있으면 아무런 작업도 수행되지 않습니다.

set_many ({'key1':'v1','k2 ':'v2'})

get_many(['key1','key2'..]) 목록의 키 값을 가져옵니다. 반환 값은 표준 Dictionary

delete( 'key')

delete_many(['key1','key2']) 키가 존재하지 않는 경우

clear() 모든 캐시 삭제

close()는 캐시

cad.incr('key',value)는 cad['key']+=value와 동일합니다. 물론 단지 동일하며 이렇게 할 수는 없습니다

맨 아래 레이어는

new

_value = value + delta

를 사용하고 값이 'a'일 때 +를 사용할 수 있는 한

cad에서도 가능합니다. decr('key',value) 빼기, 위와 동일

캐시 버전: VERSION은 동일한 키를 전달할 수 있지만 다른 값을 저장할 수 있으며 버전을 통해 구현됩니다

cad .set('key1 ','valu',version=3) key1을 버전3으로 설정,

ca.set('aa','dd',version=3)

ca .set('aa' ,'e',버전=4)

print(ca.get('aa',version=3)) #=> dd

print(ca.get('aa',version=4)) #=> 🎜>

incr_version('key',value) 마찬가지로 value는 +-

decr_version('key',value)

을 지원하지만 str을 직접 사용하는 것은 권장되지 않습니다. . 자체 클래스

를 사용하는 것은 권장되지 않지만, 버전을 채우기 위해 사용자 정의 클래스를 사용해야 하는 경우 다시 작성해야 하는 메소드는 (python3.x)

str

추가

하위

위 내용은 Django가 임시 데이터를 전송하는 방법에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!