On 17.02.2016 09:54, Katie Filbert wrote:
...
I think it would be nice if having a graph with query on a page does not
too much adversely affect the time it takes to save a page. (e.g. if
running the query takes 20 seconds..., and instead reuse cached query
results) And not have such usage kill / overwhelm the query service, is
also important.
If we incorporate entity usage or something like that, then maybe that
could be used to handle cache invalidation in cases something used in a
query changed.
This might be one of the more complex cache maintenance strategies that
I had delegated to BlazeGraph above. It is not too hard to monitor
objects in a query result for changes, but for cache invalidation to
work reliably, you would also have to watch out for items that are only
becoming part of the result because of the changes. For example, a query
for the largest cities would need to be updated if someone creates a new
city (item) that is larger than all other cities. So you have to monitor
all items to update the query, not just those used in the current result.
Markus
_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org>
https://lists.wikimedia.org/mailman/listinfo/wikidata
--
Katie Filbert
Wikidata Developer
Wikimedia Germany e.V. | Tempelhofer Ufer 23-24, 10963 Berlin
Phone (030) 219 158 26-0
http://wikimedia.de
Wikimedia Germany - Society for the Promotion of free knowledge eV
Entered in the register of Amtsgericht Berlin-Charlottenburg under the
number 23 855 as recognized as charitable by the Inland Revenue for
corporations I Berlin, tax number 27/681/51985.
_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
