On 26/07/12 16:03, Jeroen De Dauw wrote:
> Hey,
>
> > Various queries can have the same condition but different parameters
> (e.g., showing it in a table vs. showing it in a list).We should only
> have one cache for two queries that have the same results.
>
> Fully agree with this. I'm proposing to cache the result of a queries,
> not the visualizations of them. So the cache key would consist of the
> conditions, the printouts, offset, limit, sort, and perhaps some other
> relevant parameter I'm forgetting.
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. The latter would be more like a blob of data,
the former would be more like a category table ("page|query"). Both
would have their use, I suppose, but the query display as a whole is
already cached in the parser cache, so it might not be needed to cache
the whole thing again. 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). On the other hand, it would be even more useful to
cache all results per (sub)query, ignoring the limit ... not sure if we
could afford this [would not be necessary for subqueries that are
already stored in such a literal way, like namespace or category queries].
>
> > We can still have a query table (it would be interesting to store
> information about individual queries beyond the condition they have).
>
> You need this either with this approach or the one you're arguing
> against no?
You probably want it in any case. That's what I meant.
Markus
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
