On Sat, 2002-03-16 at 08:36, mlw wrote:
> Triggers and asynchronous notification are not substitutes for real hard ACID
> complient caching. The way you suggest implies only one access model. Take the
> notion of a library, they have both web and application access. These should
> both be able to use the cache.
>
Well, obviously, you'd need to re-implement the client side cache in
each implementation of the client. That is a down side and I certainly
won't argue that. As for the "no substitute" comment, I'm guess I'll
plead ignorance because I'm not sure what I'm missing here. What am I
missing that would not be properly covered by that model?
> Also, your suggestion does not address the sub-select case, which I think is
> much bigger, performance wise, and more efficient than MySQL's cache.
I'm really not sure what you mean by that. Doesn't address it but is
more efficient? Maybe it's because I've not had my morning coffee
yet... ;)
>
> This whole discussion could be moot, and this could be developed as an
> extension, if there were a function API that could return sets of whole rows.
>
Maybe...but you did ask for feedback. :)
Greg
