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

[jens]

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

[jens]

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

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

[mitsuhiko]

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

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

[jens]

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