Re: Caching Options
Hi i also use johhny cache, why it not hit your cache? Johny cache will cache your queryset and update it when the database table for the queryset updated. I only cache the queryset without add code in the views, johny cache handle the rest Pada 23 Agu 2012 06.46, "James" menulis: > Right now, I'm loading up some data VIA the orm. The nature of the data is > fairly complex, somewhere around 10-12 tables are touched per insert and > about twice that number referencing static helper tables. > > For production and day to day use, I've been using django-cache-machine, > but I've also been considering Johnny-caching. > > For this problem though, johnny won't work because the cache would > effectively never get hit. > > As far as Django-Cache-Machine, I don't think it's caching .get type > queries. I believe it only caches querysets, and then only when you > actually iterate over them. > > Considering most of my references are .get type queries for this > operation, I would think that caching those type of queries would be useful > for me during this process. > > Now, I won't have to go through this that often, maybe once ever four > months, but still I think caching some of the queries up front could speed > this up. > > What are peoples thoughts on this? > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/pvdY4dz4LdgJ. > 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.
Caching Options
Right now, I'm loading up some data VIA the orm. The nature of the data is fairly complex, somewhere around 10-12 tables are touched per insert and about twice that number referencing static helper tables. For production and day to day use, I've been using django-cache-machine, but I've also been considering Johnny-caching. For this problem though, johnny won't work because the cache would effectively never get hit. As far as Django-Cache-Machine, I don't think it's caching .get type queries. I believe it only caches querysets, and then only when you actually iterate over them. Considering most of my references are .get type queries for this operation, I would think that caching those type of queries would be useful for me during this process. Now, I won't have to go through this that often, maybe once ever four months, but still I think caching some of the queries up front could speed this up. What are peoples thoughts on this? -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/pvdY4dz4LdgJ. 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.
Re: caching options
On Tue, Dec 22, 2009 at 3:14 PM, Victor Loureiro Lima wrote: > You can purge the cache whenever you need and update it accordingly. another strategy is to use the most volatile data as part of the cache key. that would ensure that new data would ask for inexistent cache entries. the old ones would eventually expire. for example, if your records are never modified, but instead you add new to replace the old ones, then your cache should be keyed on the record ID. it's not as generally applicable, but when possible, allows for big simplifications of the cacheing layers. -- Javier -- 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.
Re: caching options
You can purge the cache whenever you need and update it accordingly. You would then have a granular cache system ( or low-level cache ). You would have to update the cache whenever the object it self is updated... Pretty common actually.. Victor Lima 2009/12/22 Continuation > I looked at the doc and it seems that django's caching system is > based on time - you have to define how long a cached page or view will > live. > > For my case (and for a lot of people I'd imagine) that wouldn't work. > For example in generating an inox list list or "how many new messages > you have" count, I can't specify beforehand how long a cached element > will live - it will live as long as the underlying data has not been > updated. > > How do you handle situations like this? I guess what is needed is read- > through and write-through cache of individual objects. Is that > something that can be done with django? > > -- > > 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. > > > -- 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.
caching options
I looked at the doc and it seems that django's caching system is based on time - you have to define how long a cached page or view will live. For my case (and for a lot of people I'd imagine) that wouldn't work. For example in generating an inox list list or "how many new messages you have" count, I can't specify beforehand how long a cached element will live - it will live as long as the underlying data has not been updated. How do you handle situations like this? I guess what is needed is read- through and write-through cache of individual objects. Is that something that can be done with django? -- 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.
