> I could indeed, as you correctly point out, put it in a cronjob provided
> that i can access the cache that is currently used byt the site.
> I haven't yet found how to do that. Probably not that hard.
> But i don't see a benefit to putting the code in a cronjob.
> Apparently, you do, so could you enlighten me? :)

  Well, it probably depends on the frequency od data change as well as
other factors. I personally don't like spawning another thread in a
request-response cycle, but if it works for you, be happy with it :)

  Based on the print statement on your code I assume your website does
run under the development server, so you may have very different
requirements than a usual production (read: always running) site :)

> As for the cache key, i did the reverse because i thought i had
> read in the documentation that this was the standard way Django puts
> stuff in the cache.

  Sure - you can do it, no problem. The reason Django uses it is that
it caches various pages and the url pattern is a good way to make sure
that the cache key is unique for each page. You could put anything
there, even a static string :)

> But it's not the link as returned by reverse, though i haven't found yet
> what it is. If i find it, i can set i correctly in the thread so that I don't
> have to manually check to see if the page is cached when a statistics page
> is called.

  You will always have to check it, as it's not guarranteed to stay in
the cache forever. Assuming that the data is in cache is a Bad Thing
:)

  If you set your cache key to "yearly_statistics" or something
similar, you will have no issue with figuring out what the key is :)

  Cheers

    Jirka

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to