On 29/07/2010 15:41, Jirka Vejrazka wrote: >> ret_val = stats_top_callers_per_year(_request) >> cache.set(reverse("stats_top_callers_per_year"), ret_val) > > Hi, > > it's your code and I won't try talk you out of it :) > > However, I don't see any reason why you couldn't call > "stats_top_caller_per_year" from an external script, unless you do > some magic related to request in that function. You're overriding the > user to be the one with pk=1 anyway, so you can do the same in a > script launched by cron the same way. > > As long as you have a system-wide cache (ideally memcached backend), > nothing prevents you from doing that. > > As for the cache key, it can be anything you want as long as it's > unique, less than the backend allows (I think it's 250 chars for > memcached, see the docs) and does not contain whitespaces (some cache > backends do allow those). A common idiom is an md5 of something that > uniquely identifies the cache object, but in your case you'd be free > to call it "stats_top_callers_per_year" or similar. No need to play > with reverse(). > > It's all just Python and Django does not really get much in a way > unless needed. So, no one tells you what the cache keys must look > like, and it's unlikely that you'd stumble upon cache keys Django uses > internally. > > HTH > > Jirka >
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? :) There are probably some good and valid reasons. The reason why i like the current approach, is that it's just 1 action to start the site and there is no need to check other things if something goes wrong. I can tell my colleagues to just start the site and that's it. 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. 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. Regards, Benedict -- 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.