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.
