django CacheMiddleware: Nur *ein* view cachen...

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

django CacheMiddleware: Nur *ein* view cachen...

Beitragvon jens » Donnerstag 21. Juni 2007, 11:58

Ich hab mich gerade mit dem caching von views in django beschäftigt.

Ich möchte in PyLucid nur einen einzigen view cachen, nämlich nur der normale CMS page request.

Meine Lösung sieht so aus, das ich mir eine eigene cache middleware gebaut hab. Also ich erbe von der normalen CacheMiddleware und prüfe nach ob der view auch der ist, der gecached werden sollte, ansonsten wird das caching ausgeschaltet.

Code: Alles auswählen

from django.middleware.cache import CacheMiddleware

class PageCache(CacheMiddleware):
    """
    change a little bit the operation method of the django CacheMiddleware:
    -Cache only the normal cms page view.
    So the _install and _command view would be not cached.
    """
    def process_view(self, request, view_func, view_args, view_kwargs):
        if view_func.func_name != "index":
            # Cache only the normal cms page view
            request._cache_update_cache = False

siehe http://pylucid.net/trac/browser/branche ... y?rev=1090


Normalerweise müsste man das selbe mit dem "The per-view cache" erreichen können:
http://www.djangoproject.com/documentat ... view-cache

Nutzte ich das, so bekomme ich aber immer einen Fehler:
The Django cache middleware with CACHE_MIDDLEWARE_ANONYMOUS_ONLY=True requires authentication middleware to be installed. Edit your MIDDLEWARE_CLASSES setting to insert 'django.contrib.auth.middleware.AuthenticationMiddleware' before the CacheMiddleware.

Ich hab allerdings als erstes die SessionMiddleware und gleich danachdie AuthenticationMiddleware in der MIDDLEWARE_CLASSES drin.

Schalte ich CACHE_MIDDLEWARE_ANONYMOUS_ONLY aus, dann kommt der nächsten Fehler:
ViewDoesNotExist: Tried index in module PyLucid.index. Error was: 'function' object has no attribute 'method'


Nehme ich den Decorator "@cache_page(60 * 15)" wieder weg, geht der view wieder, halt ohne Cache.
Nutzte ich statt dem Decorator die "alte" Variante: "index = cache_page(index, 60 * 15" geht der view zwar auch wieder, aber wird nicht gechached :(

EDIT1:
Gerade das http://code.djangoproject.com/ticket/4421 gesehen. Also hab ich mal statt index = cache_page(index, 60 * 15) das ganze in der Variante: index = cache_page(60 * 15)(index) geschrieben.
Siehe da mit der Variante kommt es zum selben Fehler, wie mit @cache_page(60 * 15)...

EDIT2:
Hm! Noch was gefunden: http://groups.google.com/group/django-d ... c3215683c/
Und jetzt wird es richtig merkwürdig!
Ich hab es mal mit index = cache_page(index) und @cache_page probiert. Siehe da es klappt schon fast.
Das komische: Der django-dev-Server verhält sich etwas anders, als die Apache-CGI Version. Beide nutzten aber CACHE_BACKEND = 'file:///tmp/PyLucid_cache'. Beide nutzten sowieso die selbe settings.py...
irgendwie scheint das richtig Buggy zu sein...

EDIT3: Hab mal ein neues Ticket geschrieben: http://code.djangoproject.com/ticket/4649

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Freitag 22. Juni 2007, 10:39

Django verfolgt da ja eine komische Philosophie:
http://code.djangoproject.com/ticket/4649

Die Dokumentation zeigt einen Weg auf, der so nicht funktioniert, weil darin ein Bug ist. Der ist bekannt, aber die Dokumentation möchte man nicht ändern. Nette Sache :evil:

Dumm das ich mich nicht so gut ausdrücken kann um den das klar zu machen. :roll:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Beitragvon mitsuhiko » Freitag 22. Juni 2007, 13:38

jens hat geschrieben:Die Dokumentation zeigt einen Weg auf, der so nicht funktioniert, weil darin ein Bug ist. Der ist bekannt, aber die Dokumentation möchte man nicht ändern. Nette Sache :evil:


1. Regel: Never break backwards compatibility. Bis die eine Lösung haben wird nichts geändert. Fühle dich frei eine Diskussion auf Google Groups oder im IRC zu starten.

//EDIT: freud'schen entfernt 8)
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Freitag 22. Juni 2007, 14:05

blackbird hat geschrieben:1. Regel: Never break backwards compatibility. Bis die eine Lösung haben wird nichts geändert.

Dagegen ist ja nichts zu sagen. Allerdings hat das mit der Sache eigentlich nichts zu tun. In der Doku steht eine Lösung die momentan so nicht funktioniert. Das ist bekannt, einige User sind darüber schon gestolpert. Nun hatte ich mit dem Ticket eigentlich gemeint, das die in der Doku was ändern sollten. Aber nein, dort bleibt alles so wie es ist, denn eigentlich sollte es ja so gehen, wenn der Bug weg ist.

Das halte ich für falsch.

EDIT: btw. der eigentliche Bug, warum das in der Syntax nicht geht, wie es in der Doku drin steht, ist mittlerweile zwei Jahre alt: http://code.djangoproject.com/ticket/1015 :roll:
Also steht seit zwei Jahren was in der Doku, was so nicht geht :?:

EDIT2: Ich hab es dann doch nochmal zu Diskussion gestellt: http://groups.google.com/group/django-d ... 2c1eff6db3

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder