Ausführliche Erklärung, wie Django temporäre Daten überträgt

Um die kürzlich verwendete temporäre Datenübertragung zusammenzufassen

Es gibt drei Methoden: Cookie,Sitzung,Cache

Lassen Sie mich zunächst erklären, wie ich Cookies auswähle. Ich verwende sie nicht Oftmals werden Cookies von Benutzern deaktiviert und müssen zusammen mit der HttpResponse weitergegeben werden. Es gibt Einschränkungen.

Gleiches gilt für Sitzungen. Wählen Sie bei der Konfiguration keine Cookies und befolgen Sie einfach die Standarddatenbank des Systems.

Cache Im Speicher ist es bequem und einfach zu verwenden, aber es nimmt nur Speicher ein.... Es kann auch entsprechend der tatsächlichen Situation in der Bibliothek abgelegt werden

Das Folgende ist die Konfiguration und Verwendung dieser drei Methoden

Eins: Cookie

• Cookie abrufen

HttpRequest.COOKIES

Ein Standardwörterbuch zurückgeben

Enthält alle Cookies, die Schlüsselwerte sind str

• Speichercookie

HttpResponse.set_cookie(key, value='', max_age=None, Expires=None, path='/', domain=None, secure=None, httponly =Falsch)

max_age wird in Sekunden festgelegt und gespeichert. Die Dauer, wenn es „Keine“ ist, wird die Dauer mit der Client-

Domäne synchronisiert. Ein domänenübergreifendes Cookie setzen

domain=".lawrence.com" setzt ein www.lawrence.com, blogs Ein Cookie, das sowohl von .lawrence.com als auch von calendars.lawrence.com gelesen werden kann wird von der Domäne gelesen, in der es festgelegt ist.

kann als domian=[] geschrieben werden. Es wird kein Fehler gemeldet, aber es gibt keinen Test, ob es wirklich standortübergreifend möglich ist

httponly= False Wenn es auf True gesetzt ist, wird verhindert, dass das js des Clients Cookies liest

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

• Löschen Sie das durch den Schlüssel angegebene Cookie, wenn nichts passiert, wenn das Cookie nicht existiert
  Wenn set_cookie den Pfad angibt und Domäne, sie sollten beim Löschen konsistent sein, sonst werden sie nicht gelöscht

Andere Inhalte

Da es sich um ein Standardwörterbuch handelt, fordern Sie es an .COOKIES['key']='value' kann den Inhalt auch in das Cookie einfügen, aber wenn es an die nächste Ansicht übergeben wird, geht der Wert verloren

Das in einer Ansicht gesetzte Cookie muss sein an die nächste Ansicht übergeben, bevor sie verwendet werden kann, wie zum Beispiel:

• 2: Sitzung

im Middleware-Plug-In-Set verwenden.

django

.contrib hinzufügen .sessions.middleware.SessionMiddleware

django1.10 für MIDDLEWARE, 1.08 für MIDDLEWARE_CLASSES

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就没有了

und es sollte „django.contrib.sessions“ in INSTALLED_APPS geben

Sie können festlegen Die Sitzung soll auf Cookie, Datei, Speicher und Datenbank basieren

Basierend auf der Datenbank „django.contrib.sessions“ zu INSTALLED_APPS hinzufügen

Nach Abschluss der Konfiguration führen Sie manage.py migrate aus

• Setzen Sie SESSION_ENGINE basierend auf der Datei auf „django.contrib.sessions.backends.file“.

Gleichzeitig können Sie SESSION_FILE_PATH festlegen, um den Speicherort der Datei anzugeben. Andernfalls verwenden Sie den Systemstandardwert /tmp

• Cookie-basierte Sitzung, nicht empfohlen, da Kunden festlegen können, dass keine Cookies verwendet werden sollen

Setzen Sie SESSION_ENGINE auf „django.contrib.sessions.backends.signed_cookies“

• Basierend auf

  Cache

  kann die Sitzung auf Cache-basiert eingestellt werden, wenn der Cache eingerichtet und der Cache-Speicherort auf Speicher eingestellt ist Nur wenn der Cache
Memcached

als Backend verwendet

• Ansonsten ist es besser, den Cache direkt zu verwenden, der flexibler ist und eine geringere Last hat

  SESSION_ENGINE kann direkt in der äußersten Ebene von Setting.py eingestellt werden Setting.py

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

Sitzung verwenden

Session-Basisklasse

backends.base.SessionBase

• Sitzung anzeigen
  request.session Holen Sie sich ein Standardklassenwörterbuch

Die Methode ist auch die gleiche wie das Wörterbuch (Verwenden Sie keine privaten Methoden)

session['fav_color'] = 'blue' Sitzung festlegen

get(key, default=None)

Zum Beispiel: fav_color = request.get('fav_color', 'red')

pop(key) löscht den Schlüssel -value-Paar und gibt den Wert zurück

Zum Beispiel: fav_color = request.session.pop('fav_color')

keys()

items()

setdefault(key[,default=None]) Gibt den entsprechenden Wert zurück, wenn der Schlüssel vorhanden ist, und legt das Schlüssel-Wert-Paar fest, wenn es nicht vorhanden ist. Zum Wörterbuch hinzufügen und den Standardwert zurückgeben

clear

()

Spezielle Methoden

flush()

Löschen Sie die aktuellen Sitzungsdaten und löschen Sie die Cookies der Sitzung. Dieser Vorgang kann verwendet werden, wenn sich der Benutzer abmeldet

set_expiry(value) zum Festlegen der Sitzungs-Timeout-Länge

Wert kann auf eine positive Ganzzahl, Datentime/ timedelta,0,None

Ganzzahl (Sekunden) Ablauf, wenn n Sekunden lang keine Operation ausgeführt wird

datatime/timedelta Läuft zu diesem Zeitpunkt ab

0 Läuft ab, wenn der Browser geschlossen wird

None Identisch mit dem globalen Standardwert

get_expiry_age() Die Zeitdauer bis zum Ablauf der Sitzung. Gibt „None“ zurück, wenn die Sitzung abgelaufen ist, oder die Ablaufinformationen ist nicht angepasst

Schlüsselwortparameter

odification : Der letzte Änderungszeitpunkt der Sitzung, der Standardwert ist der aktuelle Wert. Sie können einen Wert davor oder danach übergeben, um zu bestimmen, wie lange er abläuft

expory Angepasste Ablaufinformationen

get_expiry_

date() Gibt das Ablaufdatum zurück, abgelaufen oder uncustomized gibt die Cookie-Speicherzeit zurück

get_expire_at_browser_close()

Gibt je nach Sitzungscookie des Benutzers „True“ oder „False“ zurück, wenn der Browser des Benutzers geschlossen wird. Läuft es ab?

clear_expired()-Klassenmethode Löscht abgelaufene Sitzungen aus dem Sitzungsspeicher.

cycle_key() erstellt eine neue Sitzung unter Beibehaltung der aktuellen Sitzungsdaten.

Drei: Cache verwenden

• Cache einrichten (verwenden Sie den integrierten Hintergrund, um Memcached zu konfigurieren, wenn der Speicher ausreichend und notwendig ist)

In Dateien zwischengespeichert

CACHES = {

'default': {

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

'LOCATION': '/var/tmp/django_cache', # Dateipfad, wenn unter Windows in 'c:/tmp/django_cache' geändert

}

}

Der Pfad ist ein absoluter Pfad, ein Verzeichnis, das die 42 (Lese- und Schreib-) Berechtigungen des aktuellen Benutzers erfordert

In der Datenbank zwischengespeichert

CACHES = {

'default': {

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

'LOCATION': 'my_cache_table', #Table Name, zulässig und wurde nicht verwendet

}

}

python manage.py createcachetable Erstellen Sie eine Cache-Tabelle. Der Tabellenname wird durch LOCATION

Cache im Speicher (Standard)

CACHES = {

'default': {

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

'LOCATION': 'unique-snowflake', # Der Speicher muss nur konfiguriert werden, wenn mehrere Speicher vorhanden sind, ist eine Konfiguration nicht erforderlich 🎜> }

}

Virtueller Cache: speichert nicht, behält aber die

Schnittstelle

bei, um die Konsistenz der Entwicklungs- und Produktionsumgebung sicherzustellen

CACHES = { 'default': {

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

}

}

CACHES-Parameter festlegen

• TIMEOUT Das Standard-Timeout beträgt

  300
, also fünf Minuten

VERSION Die Standard-Cache-Versionsnummer OPTIONEN: Dieser Parameter sollte an das Cache-Backend übergeben werden. Die Liste der gültigen Optionen variiert je nach Cache-Backend und Caches, die von Bibliotheken von Drittanbietern unterstützt werden, konfigurieren diese Optionen direkt in der zugrunde liegenden Cache-Bibliothek.

Das Cache-Backend implementiert seine eigene Auswahlstrategie (Datei, Datenbank, Speicher) und implementiert die folgenden Optionen:

MAX_ENTRIES: Die maximal zulässige Anzahl von Einträgen im Cache, wenn diese überschritten wird Zahl, es wird alt sein. Der Standardwert dieses Parameters ist 300.

CULL_FREQUENCY: Das Verhältnis der gelöschten Einträge, wenn MAX_ENTRIES erreicht ist. Das tatsächliche Verhältnis beträgt 1 / CULL_FREQUENCY. Wenn Sie also CULL_FREQUENCY auf 2 setzen, wird die Hälfte des Caches gelöscht, wenn der durch MAX_ENTRIES festgelegte Wert erreicht ist. Dieser Parameter sollte eine Ganzzahl sein, der Standardwert ist 3.

Wenn Sie den Wert von CULL_FREQUENCY auf 0 setzen, bedeutet dies, dass der Cache geleert wird, wenn MAX_ENTRIES erreicht ist. Bei einigen Cache-Backends (insbesondere Datenbanken) geht dies mit vielen Cache-Fehlern einher.

Beispiel:

wird im Speicher zwischengespeichert und die Zeitüberschreitung beträgt 60*10 600 Sekunden, 500 Elemente werden zwischengespeichert, jedes Mal 1/5 löschen

CACHES = {

'default': {

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

'TIMEOUT': 600,

'OPTIONS': {

'MAX_ENTRIES': 500,

'CULL_FREQ UENCY': 5

} }

}

}

• Cache-Strategie: Die gesamte Site zwischenspeichern, die Ansicht zwischenspeichern, Vorlagenfragmente zwischenspeichern

• Die gesamte Site zwischenspeichern:

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

]

Achten Sie auf die falsche Reihenfolge

Fügen Sie dann den Wert in der äußersten Ebene von Setting.py hinzu

CACHE_MIDDLEWARE_ALIAS – der Alias ​​für den gespeicherten Cache , wenn nicht festgelegt, ist es „Standard“ '

CACHE_MIDDLEWARE_SECONDS – Wie viele Sekunden jede Seite zwischengespeichert werden muss.

CACHE_MIDDLEWARE_KEY_PREFIX – Wenn der Cache von mehreren Websites mit demselben Django gemeinsam genutzt wird Installation, dann wird dieser Wert auf den aktuellen Website-Namen oder eine andere eindeutige Zeichenfolge gesetzt, die diese Django-Instanz darstellt, um Schlüsselkonflikte zu vermeiden. Wenn es Ihnen egal ist, können Sie es auf eine leere Zeichenfolge setzen.

Einzelansicht-Cache

von django.views.decorators.cache import cache_page

@cache_page(60 * 15)

def my_view(request):

pass

Mehrere URLs verweisen auf dieselbe Ansicht. Jede URL wird separat zwischengespeichert, z. B.:

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

foo/12

foo/13 verwendet unterschiedliche Caches, aber beide 12 verwenden dasselbe

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

Beispiel: Verwendet nur den angegebenen Cache

CACHES = {

'default': {

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

'TIMEOUT': 600,

'OPTIONS': {

' Max_Entries ': 500,

'Cull_frequenz': 5

}

},

'Special_cache': {

'TIMEOUT': 600,

'OPTIONS': {

'MAX_ENTRIES': 500 >Wenn Sie Sie müssen auf /cache/ und /nocache/ zugreifen. Sie verweisen ebenfalls auf dieselbe Seite, aber eine wird zwischengespeichert und die andere nicht.

Sie können angeben, welche Seite in der URL und nicht in der Ansicht zwischengespeichert werden soll

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

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

Vorlagencache

{% Ladecache %}

{% Cachedauer (Sekunden) Name%}

{% endcache name%}

Flexiblere Nutzung des Caches

Importieren Sie die Caches von django.core.cache in Ansichten

cad = Caches['default'] # The Der Name ist hier derselbe wie in CACHES. Die Konfiguration ist derselbe. 'value',duration) Wenn die Dauer nicht festgelegt ist, wird ein Standardwert oder ein benutzerdefinierter Wert verwendet.

cad.get('key') Wenn der Schlüssel nicht vorhanden ist, wird „None“ zurückgegeben Geben Sie auch den Standardwert get('key','default value') an. Wenn kein Schlüssel vorhanden ist, wird '

cad.add('key','value')' zurückgegeben. Wenn der Schlüssel nicht vorhanden ist, fügen Sie einen Schlüsselwert hinzu. Wenn der Schlüssel bereits vorhanden ist, wird keine Operation ausgeführt. Der Wert ist immer noch der vorherige Wert

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

get_many(['key1','key2'..]) Holen Sie sich den Wert des Schlüssels in der Liste. Der Rückgabewert ist Standard Dictionary

delete(' key')

delete_many(['key1','key2']) Wenn der Schlüssel nicht existiert

clear() alle Caches löschen

close() schließt den Cache

cad.incr('key',value) ist äquivalent zu cad['key']+=value Natürlich ist es nur äquivalent und kann nicht so gemacht werden

Seitdem unten Die Ebene verwendet

new

_value = value + delta

. Wenn der Wert „a“ ist, ist dies auch möglich, solange +

cad.decr verwendet werden kann ('key',value) minus, wie oben

Cache-Version: VERSION kann denselben Schlüssel übergeben, aber unterschiedliche Werte speichern, implementiert durch version

cad .set('key1' ,'valu',version=3) Setze key1 auf 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) Ebenso unterstützt value +-

decr_version('key',value)

Es wird jedoch nicht empfohlen, str direkt usw. zu verwenden . Es wird nicht empfohlen, Ihre eigene Klasse

zu verwenden. Wenn Sie jedoch wirklich eine benutzerdefinierte Klasse verwenden müssen, um die Version zu füllen, müssen folgende Methoden neu geschrieben werden: (python3.x)

str

add

sub

Das obige ist der detaillierte Inhalt vonAusführliche Erklärung, wie Django temporäre Daten überträgt. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!