search

ph87 / django-logging

Automatically exported from code.google.com/p/django-logging
0 stars 0 forks source link

Configuration for cache integration #8

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I'd like to use djangologging to determine when a page is returned from the
standard django cache and when django hits the database.

Do you have a suggestion for where to put djangologging middleware relative
to django.middleware.cache.CacheMiddleware?

I have the following settings:

    # djangologging params
    LOGGING_OUTPUT_ENABLED = True 
    LOGGING_LOG_SQL = True

If I put djangologging after CacheMiddleware, the request log is appended
to the HTML on the first request, but subsequent requests will show simply
this same cached HTML - including the request log html.

If I put djangologging before CacheMiddleware, subsequent page loads show
the request log snippet repeated -- but with "No log entries.". Each page
load adds another. 

This does show me that I'm not hitting the db, but it's not clear to me why
 I get more than one extra request log bar.

Any thoughts on this?

Original issue reported on code.google.com by dhar...@gmail.com on 12 Dec 2007 at 6:12

GoogleCodeExporter commented 9 years ago 
When djangologging is installed after CacheMiddleware, the order of events is 
as follows:

djangologging   - process_request
CacheMiddleware - process_request
View function (or cached response)
CacheMiddleware - process_response
djangologging   - process_response

If the page is in the cache, CacheMiddleware's process_response returns the 
cached
response object, to which djangologging's process_response appends the HTML 
output. 

Since it is a single HttpResponse instance that is being manipulated, when you
re-request the page and CacheMiddleware returns it from it's cache a second 
time,
that instance has already had the HTML appended to it before and is just 
appended to
again and again.

Technically this seems to be correct, though may not be the most ideal 
behaviour. I'm
open to suggestions of how this might be improved.

One solution might be to change djangologging's middleware to return a copy of 
the
response and thus preventing a build-up of multiple logs. However, cloning a
HttpResponse may not be a trivial task, especially if the response is a 
file-like
object, rather than a simple string.

Original comment by fras...@gmail.com on 21 Dec 2007 at 1:13