Hey,

> On the other hand, it would be even more useful to cache all results per (sub)query, ignoring the limit

This can reduce computing overlapping results, but on the other hand is likely to compute results we'll never actually use. And it makes the implementation more complex. Since I'm not convinced the actual result would be better (I suspect that in fact it's be worse), I prefer to keep it simple for now. And if you have a case where the "store everything" approach really makes sense, you can always use a concept right?

> I was thinking of caching the query result only, not the printouts. One could cache a list of results, instead of caching all data needed to display the query result.

Similar arguments apply here. Any query obtaining a single property would automatically fetch all properties for all matching objects. Again I don't think it's that much of an improvement. Esp considering the following:

> Having the lists of query results that are displayed in one query now could be useful for updating (if you have a data blob, you cannot check quickly for which queries a page occurs as a displayed result).

Sure, I'd make it easier to figure this out. At least, if you go invalidate it whenever a single property changes. So now our query obtaining a single property does not only result into all properties getting obtained, but it'll also have it's cache invalidated whenever one of those other properties is changed. This seems like something we really should avoid, so we'll have to hold into account the affected properties anyway, making the "just store all properties" approach not simpler to implement.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--