Hackathon notes (non-binary protocol thread), (BUSTARRET, Jean-francois)

[Jan Miczaika]

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
>
>