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
signature.asc
Description: This is a digitally signed message part