May be you can try database long connection. On Fri, Aug 19, 2011 at 10:44 AM, Andre Terra <andrete...@gmail.com> wrote:
> 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 <felipe.arruda.pon...@gmail.com> 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 <dball...@gmail.com> 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 django-users@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. > > > > > > -- > 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 django-users@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. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
