I think a better solution would be to use a store rather than cache (protip: redis) and, if the calculations are lengthy, write a 'publish' function that writes them to the store and let the user choose when to see the changes in the results appear on the website.
Additionally, add a 'modified since last publish' flag that is switched on with post_save and off with publish(). And of course, use celery for running the calculations in the background. Here, redis doubles (or triples!) as the result and broker backends (see the celery docs for more info on that). Cheers, AT On 8/18/11, Felipe Arruda <[email protected]> wrote: > Humm, I see, the second case I could make out of it somehow(just have > some doubts in 2.5: How am I supposed to do this?) > The first one I could't see how I'm not going to lose the changes, > done in cache. > My biggest problem is in altering some value in some models, since > this operation will be done many times, and I can't do if not by > this(so that the client infos wont be any different from the DB), and > for what I understand from this solution I would work if my operations > where simple retrieving data from the server and doing some > calculation, but will lose the informations in cache(substituting it > from the DB. I want it to be otherwise). > > And about the django-celery: Never heard about it, but now I'm going > to use it(but for other purposes, and other projects too). Thanks for > the tip! > > Another thing. I thought of doing something like this: > Use MemCache, and the second ideia presented, put like a very long > time, and run a parallel task(using celery? or maybe some thing in > django-extensions that integrate with cron), so that from time to > time(a more reasonable time then the timeout from the cache) it will > get every info from cache and save it in the DB. > This way, in the worst case, every 10 minutes the system would have a > small halt to save things(or could make a more complex way to save > each register in different times). > What do you thing about it? To much POG, or is in the right track? > > On Aug 18, 3:57 pm, Doug Ballance <[email protected]> wrote: >> You probably don't want to cache changes. Or if you do, it would be >> better done elsewhere (like a caching raid controller/w battery on >> your database machine). The usual cache patterns I've seen are: >> >> 1) Fetch from database >> 2) Store in cache with a reasonable timeout to that changes are >> reflected as the cache expires >> 3) Look in cache, if found return that. If not goto step (1) >> >> or >> >> 1) Fetch from database >> 2) Store in cache with a -long- timeout >> 2.5) Track changes to cached objects and update the stored information >> if it changes. >> 3) Look in cache, if found return it. if not goto step(1) >> >> since the changes won't be reflected as rapidly due to the long >> timeout, you can configure the post_save/post_delete/etc signals to >> automatically update the cached value every time a change is made to >> one of that models instances. This is what the django-cache-utils app >> is doing for you. The trick is that the more complicated your use, >> the more complex the cache invalidation is going to have to be. >> >> Another possiblity is that caching may be the wrong solution to your >> problem. If for example a web request need to do so a bunch of >> expensive operations, but does not need to do them interactively with >> your user, a solution like django-celery may be better. With celery >> the job gets scheduled for execution outside of the web request- >> response system (possibly even on another machine) and gives you a job >> id. This allows the user to get on with things, leaving the work to >> be done behind the scenes. If the user needs to know the results or >> state of the job you can use ajax or refreshing to check back using >> the id to retreive the results when the job completes. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Sent from my mobile device -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
