Hackathon notes (non-binary protocol thread), (BUSTARRET,
jan at hitflip.de
Wed Jul 18 08:38:47 UTC 2007
Yes, it may expensive as well. But we can incorporate it in our
workflow. DVD has a new relationships with an actor - tag the actor's
key with the DVD's id as well as the DVD's ID with the actor's. May
possible lead to a kind of cascading flushing.
We have played around with integrating tagging in the application. We
were testing SQLite as a tag database. Or mySQL memory tables if you
make all keys ints. But I think it would be more elegant to have all
functionality in one product rather than craft on something different.
Zend_Cache offers tagging as a feature and Memcached as one of several
backends. I'll swing around and look how they implemented it.
>> Point 2 multiplies for each loosely related keys. The direct ones are
>> easy to hit, the others not so.
> I think this makes sense, but it seems like you're shifting the
> problem over to tagging. Now you have to tag James Hong with every
> role he's been involved in in case the DVD availability of one of them
> changes. That seems like it would be just a different expensive.
> It seems like you could do the same thing just as easily in your
> app at that point. e.g. if I'm invalidating a movie, I probably have
> an actor list and can just asynchronously fire off concurrent
> deletions to all the related actors and stuff (or better, just
> asynchronously send updated information).
> --Dustin Sallings
More information about the memcached