It's probably bigger question than just allowing users to clear the cache - how to purge cache automatically when data is supposed to change.
In theory, all the data that needs to be tracked is already defined within the query itself and it might be possible to derive cache invalidation rules from them. I'm not very sure how to do the parsing, but the rules might be saved in the form of "Updated_property_name, additional_condition, Page_to_be_purged" where "Updated_property_name" values are derived from the query and "Page_to_be_purged" is the name of the page that contains the query.

Then upon page update/new page creation, all Updated_property_name values are checked, additional_condition is verified (just to minimize the load) and cache of appropriate "Page_to_be_purged" are marked as expired and get revalidated upon next load.

This kind of extension can be written and added to SMW Data store, probably, but it is only needed when you have to have very quick updates on the pages, otherwise, just wait till natural page expiration - it'll happen eventually.

           Sergey


On Fri, Apr 25, 2008 at 3:39 PM, Matthew Williamson <matthewdw@gmail.com> wrote:
Joe,

Your analysis is mostly correct, except that the caching behavior you observe is actually a function of MediaWiki, rather than Semantic MediaWiki. You could eliminate the behavior, I believe, by tweaking MediaWiki's configuration. But you're also correct that in many cases this can be good--the cached output is a performance saver, especially for large wikis/highly trafficked wikis/wikis where the data doesn't change that often. I think if the feature you suggested were made a default part of SMW, it would largely negate the benefits of the caching mechanism, because people would tend to click that "refresh" button just because it was there.

However, there's an easy way to do what you describe, and I have this exact feature in one of my wikis. Just add a template named Template:CacheBust to your wiki with the following contents:

Data current as of {{CURRENTMONTHNAME}} {{CURRENTDAY}}, {{CURRENTYEAR}}, {{CURRENTTIME}}. [{{fullurl:{{FULLPAGENAME}}|action=purge}} Clear cached data]

...Then, add a call to the template {{CacheBust}} either above or below queries you anticipate needing frequent refreshing. This template shows the age of the data (because the variables are cached at the same time), and makes it easy for the user to purge the cache if it looks too old. You might have to tweak the {{fullurl:...}} part if your wiki isn't set up with rewrite rules, but other than that, this solution should be pretty generally applicable.

-Matt



On Fri, Apr 25, 2008 at 1:16 PM, Joe Clark <joeclark@joeclarkia.net> wrote:
I've done a little more testing of the SMW "inline query" mechanism.  My
"use case" here is creating an automatically up-to-date list of TODO
items.  Consider this:

* I created a template using two annotation types: todo-title, todo-text.
* I create a Todo List page which will store the list of todo items.. that
is, it contains the inline query.
* I create a few pages which use the template, in effect adding "TODO"
items to those pages.
* I reload the Todo List page, and.. nothing -- no entries.
* I edit/save the Todo List page, and.. all the todo items show up.

I assume this is the way that SMW works.  This is not really intuitive and
seems to lead to confusion about what is really in the "database" that is
the wiki.

I suppose there is a good reason for this: too much database overhead to
query every time, etc.

As a workaround, I would propose a button/icon on the list (query) display
that would refresh the data (in effect edit/save the page, but without the
user steps).  This would fit nicely into the column headers I think.  It
would also make it more obvious that the user might have to do something
to see the current list.

Any thoughts?  Am I missing something?
 - Joe


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Semediawiki-user mailing list
Semediawiki-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user




--
Sergey Chernyshev
http://www.sergeychernyshev.com/