Explication détaillée de la façon dont Django transfère les données temporaires

Pour résumer le transfert de données temporaire qui a été utilisé récemment

Il existe trois méthodes, cookie,session,cache

Laissez-moi d'abord vous expliquer comment choisir pour moi. J'ai seulement besoin de comprendre les cookies. Je ne Je ne les utilise pas souvent car les cookies des utilisateurs seront désactivés et devront être transmis avec la réponse Http. Il y a des limitations

Il en va de même pour les sessions, ne choisissez pas d'utiliser des cookies et suivez simplement le système. base de données par défaut.

cache En mémoire, c'est pratique et simple à utiliser, mais cela ne prend que de la mémoire.... Il peut également être placé dans la bibliothèque. Considérez-le en fonction de la situation réelle

Voici la configuration et l'utilisation de ces trois méthodes

Une : cookie

• Obtenir un cookie

HttpRequest.COOKIES

Renvoyer un dictionnaire standard

Contient tous les cookies, les valeurs clés sont str

• Cookie de stockage

HttpResponse.

set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure= Aucun, httponly=False)

max_age est défini et enregistré en secondes La durée, lorsqu'elle est Aucune, la durée est synchronisée avec le client

domaine Définir un cookie inter-domaines

domain=".lawrence.com" définira un www.lawrence.com, blogs Un cookie lisible à la fois par .lawrence.com et

calendars.lawrence.com. Sinon, le cookie. ne sera lu que par le domaine où il est défini.

peut être écrit comme domian=[], aucune erreur ne sera signalée, mais il n'y a aucun test pour savoir s'il peut vraiment être multisite

httponly=False Lorsqu'il est défini sur True, il empêche le

js du client de lire les cookies

• Opération de suppression

delete_cookie(key, path='/', domain=None)

Supprimer le cookie spécifié par key, quand Rien ne se passera lorsque le cookie n'existe pas

Quand set_cookie spécifie le chemin et le domaine, ils doivent être cohérents lors de la suppression, sinon ils ne seront pas supprimés

• Autre contenu

Parce que c'est un standard dictionnaire, request.COOKIES['key']='value' peut également mettre le contenu dans le cookie, mais lorsqu'il sera transmis à la vue suivante, la valeur sera perdue

Le cookie défini dans une vue doit être transmis à la vue suivante avant de pouvoir être utilisé, par exemple :

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 : Utiliser la session

dans l'ensemble de plug-ins middleware Ajouter

django.contrib.sessions.middleware.SessionMiddleware

django1.10 pour MIDDLEWARE, 1.08 pour MIDDLEWARE_CLASSES

et il devrait y avoir 'django.contrib.sessions' dans INSTALLED_APPS. Vous pouvez définir la session pour qu'elle soit basée sur un cookie, un fichier, une mémoire, une base de données

En fonction de la base de données, ajoutez 'django.contrib.sessions' à INSTALLED_APPS

• Une fois la configuration terminée, exécutez manage.py migrate

Définissez SESSION_ENGINE sur "django.contrib.sessions.backends.file" en fonction du fichier.

• En même temps, vous pouvez définir SESSION_FILE_PATH pour spécifier l'emplacement de stockage du fichier. Sinon, utilisez la valeur par défaut du système. Si elle n'est pas modifiée, il s'agit de /tmp

.

Session basée sur les cookies, non recommandée, car les clients peuvent choisir de ne pas utiliser de cookies

• Définissez SESSION_ENGINE sur "django.contrib.sessions.backends.signed_cookies"

Basé sur le

Cache
• , lorsque le cache est configuré et que l'emplacement de stockage du cache est défini sur la mémoire, la session peut être définie pour être basée sur le cache. Ceci est recommandé. seulement si le cache utilise

  Memcached comme backend

  Sinon, il est préférable d'utiliser directement le cache, qui est plus flexible et a une charge plus petite

SESSION_ENGINE peut être défini directement dans la couche la plus externe de settings.py

setting.py

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

Utiliser la session

• Classe de base de session

backends.base.SessionBase

Obtenir la session en vue

request.session Obtenez un dictionnaire de classe standard

La méthode est également la même que le dictionnaire (Ne pas utiliser de méthodes privées)

session['fav_color'] = 'blue' Définir la session

get(key, default=None)

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

pop(key) supprime la clé. -value paire et renvoie la valeur

Par exemple : fav_color = request.session.pop('fav_color')

keys()

items()

setdefault(key[,default=None]) Renvoie la valeur correspondante lorsque la clé existe et définit la paire clé-valeur lorsqu'elle n'existe pas Ajouter au dictionnaire et renvoyer la valeur par défaut

clear

()

Méthodes spéciales

flush()

Supprimez les données de la session en cours et supprimez les cookies de la session. Cette opération peut être utilisée lorsque l'utilisateur se déconnecte

set_expiry(value) pour définir la durée du délai d'expiration de la session

la valeur peut être définie sur un entier positif, datatime/ timedelta,0,None

Entier (secondes) Expiration si aucune opération n'est effectuée pendant n secondes

datatime/timedelta Expire à ce moment

0 Expire lorsque le navigateur est fermé

Aucun Identique à la valeur globale par défaut

get_expiry_age() La durée jusqu'à l'expiration de la session renvoie Aucun lorsque la session a expiré ou les informations d'expiration. n'est pas personnalisé

Paramètres des mots clés

odification : L'heure de la dernière modification de la session, la valeur par défaut est la valeur actuelle Vous pouvez passer une valeur avant ou après pour déterminer combien de temps elle expirera <.>

expory Informations d'expiration personnalisées

get_expiry_

date() Renvoie la date d'expiration, expirée ou non personnalisée renvoie la durée de stockage du cookie

get_expire_at_browser_close()

Renvoie Vrai ou Faux, selon le cookie de session de l'utilisateur lorsque le navigateur de l'utilisateur est fermé. Va-t-il expirer ?

Méthode de classe clear_expired() Efface les sessions expirées du stockage de session.

cycle_key() crée une nouvelle session tout en conservant les données de la session en cours.

Trois : Utiliser le cache

• Configurer le cache (utiliser l'arrière-plan intégré pour configurer Memcached lorsque la mémoire est suffisante et nécessaire)

Cache dans le fichier

CACHES = {

'par défaut' : {

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

'LOCATION' : '/var/tmp/django_cache', # Chemin du fichier, lorsqu'il est remplacé par 'c:/tmp/django_cache' sous win

}

>

Le chemin est un chemin absolu, un répertoire, qui nécessite les 42 autorisations (lecture et écriture) de l'utilisateur actuel

Mise en cache dans la base de données

CACHES = {

'default' : {

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

'LOCATION' : 'my_cache_table', #Table nom, légal Et il peut être utilisé s'il n'a pas été utilisé auparavant (Par défaut)

CACHES = {

'default' : {

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

'LOCATION': 'unique-snowflake', # La mémoire ne doit être configurée que lorsqu'il y a plusieurs mémoires. S'il n'y a qu'une seule mémoire, il y en a. il n'est pas nécessaire de le configurer

}

}

Cache virtuel : ne met pas en cache, mais conserve l'

interface

pour assurer la cohérence du environnement de développement et de production

CACHES = {

'default' : {

'BACKEND' : 'django.core.cache.backends.dummy.DummyCache',

>

}

Définir les paramètres CACHES

TIMEOUT Le délai d'expiration par défaut est

300

soit cinq minutes

• VERSION Le numéro de version du cache par défaut
  OPTIONS : ce paramètre doit être transmis au backend du cache. La liste des options valides varie en fonction du backend de cache. Les caches pris en charge par les bibliothèques tierces configureront ces options directement dans la bibliothèque de cache sous-jacente.

Le backend du cache implémente sa propre stratégie de sélection (fichier, base de données, mémoire) et implémentera les options suivantes :

MAX_ENTRIES : Le nombre maximum d'entrées autorisées dans le cache s'il dépasse ce nombre. numéro, il sera ancien. La valeur sera supprimée. La valeur par défaut de ce paramètre est 300.

CULL_FREQUENCY : Le ratio d'entrées supprimées lorsque MAX_ENTRIES est atteint. Le rapport réel est de 1 / CULL_FREQUENCY, donc définir CULL_FREQUENCY sur 2 supprimera la moitié du cache lorsque la valeur définie par MAX_ENTRIES sera atteinte. Ce paramètre doit être un nombre entier, la valeur par défaut étant 3.

Définir la valeur de CULL_FREQUENCY sur 0 signifie que le cache sera vidé lorsque MAX_ENTRIES sera atteint. Pour certains backends de cache (en particulier les bases de données), cela se fera au prix de nombreux échecs de cache

Exemple :

est mis en cache en mémoire et le délai d'attente est de 60*10 600 secondes, 500 éléments. sont mis en cache, supprimez-en 1/5 à chaque fois

CACHES = {

'default' : {

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

'TIMEOUT' : 600,

'OPTIONS' : {

'MAX_ENTRIES' : 500,

'CULL_FREQ UENCY' : 5

} }

}

}

• Stratégie de cache : mettre en cache l'intégralité du site, mettre en cache la vue, mettre en cache les fragments de modèle

• Cache l'intégralité du site :

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',

]

Faites attention au mauvais ordre

Ajoutez ensuite la valeur dans la couche la plus externe de settings.py

CACHE_MIDDLEWARE_ALIAS - l'alias du cache stocké , s'il n'est pas défini, ce sera « par défaut » '

CACHE_MIDDLEWARE_SECONDS – Combien de secondes chaque page doit être mise en cache.

CACHE_MIDDLEWARE_KEY_PREFIX – Si le cache est partagé par plusieurs sites Web utilisant le même Django installation, puis cette valeur définie sur le nom du site Web actuel, ou sur une autre chaîne unique qui représente cette instance de Django pour éviter les conflits de clés. Si vous ne vous en souciez pas, vous pouvez le définir sur une chaîne vide.

Cache à vue unique

de django.views.decorators.cache import cache_page

@cache_page(60 * 15)

def my_view(request) :

pass

Plusieurs URL pointent vers la même vue, chaque URL sera mise en cache séparément, comme :

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

foo/12

foo/13 utilise des caches différents, mais les deux 12 utilisent le même

@cache_page ( 60 * 15, cache="special_cache")

Par exemple : utilisera uniquement le cache spécifié

CACHES = {

'default' : {

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

'TIMEOUT' : 600,

'OPTIONS' : {

' Max_Entries ' : 500,

'Cull_fréquence' : 5

}

},

'Special_cache' : {

'TIMEOUT' : 600,

'OPTIONS' : {

'MAX_ENTRIES' : 500 >Lorsque vous . besoin d'accéder à /cache/ et /nocache/, ils pointent également vers la même page, mais l'un est en cache et l'autre ne l'est pas

Vous pouvez spécifier quelle page mettre en cache sur l'url, pas sur la vue

url(r'^cache/$', cache_page(60 * 15)(my_view), name='cache'),

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

Cache des modèles

{% chargement du cache %}

{% durée du cache (secondes) nom%}

{% endcache name%}

Utilisation plus flexible du cache

Importer les caches de django.core.cache dans les vues

cad = caches['default'] # Le le nom ici est le même que dans CACHES La configuration est la même

cas = caches['special_cache']

Méthodes couramment utilisées

cad.set('key', 'value',duration) Si la durée n'est pas définie, elle sera prise Valeur par défaut ou valeur personnalisée

cad.get('key') Si la clé n'existe pas, elle renverra Aucune Vous pouvez. spécifiez également la valeur par défaut get('key','default value'). S'il n'y a pas de clé, il renverra '

cad.add('key','value'). Lorsque la clé n'existe pas, ajoutez clé-valeur. Lorsque la clé existe déjà, aucune opération n'est effectuée. La valeur est toujours la valeur précédente

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

get_many(['key1','key2'..]) Récupère la valeur de la clé dans la liste La valeur de retour est standard Dictionary

delete(' key')

delete_many(['key1','key2']) Lorsque la clé n'existe pas

clear() supprime tous les caches

close() ferme le cache

cad.incr('key',value) est équivalent à cad['key']+=value Bien sûr, c'est juste équivalent et ne peut pas être fait comme ça

Depuis le bas la couche utilise

new

_value = value + delta

, alors lorsque la valeur est 'a', c'est également possible, à condition que + puisse être utilisé

cad.decr ('key',value) moins, comme ci-dessus

Version du cache : VERSION peut transmettre la même clé, mais enregistrer des valeurs différentes, implémentées via la version

cad .set('key1' ,'valu',version=3) Définissez key1 sur version3,

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

ca .set('aa', 'e',version=4)

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

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

incr_version('key',value) De même, value prend en charge +-

decr_version('key',value)

Mais il n'est pas recommandé d'utiliser str directement, etc. . Il n'est pas recommandé d'utiliser votre propre classe

, mais lorsque vous avez vraiment besoin d'utiliser une classe personnalisée pour remplir la version, les méthodes qui doivent être réécrites sont (python3.x)

str

ajouter

sub

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!