Event based caching

[henri...@gmail.com]

First of all, I have to say that the cache framework is golden.
It's very good for e.g. news sites and that sort - but exceptions do
occur. I would like to see event based caching implemented into
Django. The current time based cache framework doesn't always do the
trick. When you have a site with hundreds of profiles, you have to
have the possibility to let other users view updated information
**when it's updated**.

I know that Rails has the possibility to use event based caching, and
I don't see why Django doesn't have the same possibility.

[黄毅]

If i understand what you are talking about, I think it's quite easy to implement a event-based cache system using signals.

It's something like this:

 

def article_posted(article):

    touch the cached article

    touch some cached article list

dispatcher.connect(article_posted, signal=your_signals.article_post)

 

[Michael Trier]

Henrik,

I'm sure a lot of people would benefit from an event based caching
system. So I know that I for one am eagerly looking forward to seeing
your contribution.

Michael

[henri...@gmail.com]

Hi 黄毅,
That is one way of doing it, but it would be even better if it was
implicit.
I'm not sure how one would implement this into django.core.cache.
I guess Django must know the cache keys somewhere internally, but
how do we automate the process of touching the cached object on POST?

On Jun 10, 3:59 pm, "黄毅" <yi.codepla...@gmail.com> wrote:
> If i understand what you are talking about, I think it's quite easy to
> implement a event-based cache system using signals.
> It's something like this:
>
> def article_posted(article):
> touch the cached article
> touch some cached article list
> dispatcher.connect(article_posted, signal=your_signals.article_post)
>

> On 6/10/07, henrikl...@gmail.com <henrikl...@gmail.com> wrote:
>
>
>
>
>
> > First of all, I have to say that the cache framework is golden.
> > It's very good for e.g. news sites and that sort - but exceptions do
> > occur. I would like to see event based caching implemented into
> > Django. The current time based cache framework doesn't always do the
> > trick. When you have a site with hundreds of profiles, you have to
> > have the possibility to let other users view updated information
> > **when it's updated**.
>
> > I know that Rails has the possibility to use event based caching, and
> > I don't see why Django doesn't have the same possibility.
>

> --http://codeplayer.blogspot.com/

[henri...@gmail.com]

I've filed a ticket on this as well: http://code.djangoproject.com/ticket/4520

[Malcolm Tredinnick]

On Sun, 2007-06-10 at 15:23 +0000, henri...@gmail.com wrote:
> I've filed a ticket on this as well: http://code.djangoproject.com/ticket/4520

I'm not quite sure what result you are expecting from a ticket like
that, though. It doesn't contain any sample implementation or even a
proposed API, so there's no way to possibly close such a ticket. Please
consider closing it until you have something more concrete.

Discussion about an API should happen on this list, not in the ticket,
since developers are already subscribed to this list and Trac tickets
are very bad at threaded conversations.

The way forward here is to propose an API and explain how you think this
system should behave. Perhaps an example implementation to critique
would be useful, too. This is definitely "scratch your own itch"
territory: if the low-level API isn't what you want to use and the
high-level one isn't doing what you want, help to fill in the blanks a
bit. At the moment, it's just a undefined wishlist item.

Having wishlists is fine: all great features start out that way, but
I've spent a bit of time trying to work out what you are really after
here (beyond the single example case you've posted) and I still don't
have any real idea about what needs to changed or added.

Best wishes,
Malcolm

[Paul Collier]

Hello Henrik!

(I think this has to do with what you're trying to accomplish, correct
me if wrong ;) In terms of keeping cache synced with data in models,
this is something I'm trying to address with my GSoC project for the
summer[1]. In fact, the current code already has a mechanism for
tracking model updates and deletes using signals. Basically, if you
call .cache_set("mycachekey") on your existing QuerySet it'll hook up
the appropriate signals and update the cache when relevant model
instances are modified. (It also does the QuerySet lookup using the
cache rather than the database for you.) It's not very mature code
right now, though. More functionality and better implementation coming
shortly...

- Paul

[1] http://code.google.com/p/django-object-level-caching/

[henri...@gmail.com]

On Jun 11, 10:04 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

> I'm not quite sure what result you are expecting from a ticket like
> that, though. It doesn't contain any sample implementation or even a
> proposed API, so there's no way to possibly close such a ticket.

> The way forward here is to propose an API and explain how you think this
> system should behave.

The reason why there's no sample implementation is that I generally
don't really see
how it could be done myself. The current cache-framework doesn't have
any insight
into the current request (right?), so it's not able to see if the
content is provided via
POST or GET.
This is the first thing that has to be done, as far as I can see. If
the user does a POST,
the cache framework needs to delete the key for that specific content.
Does anyone have any input on how that can be accomplished?