Last modified: 2010-03-09 01:43:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T24751, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22751 - Purging a page doesn't update ("dynamic") attributes when changed
Purging a page doesn't update ("dynamic") attributes when changed
Status: RESOLVED INVALID
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Markus Krötzsch
http://sandbox.semantic-mediawiki.org...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-07 00:18 UTC by Daniel A. R. Werner
Modified: 2010-03-09 01:43 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Daniel A. R. Werner 2010-03-07 00:18:55 UTC
If you have an attribute assignment on page "pageA" e.g. like [[Attribute1::{{#show:pageB|?Attribute2 |link=none}} ]] and you change the Attribute2 value on pageB the Attribute1 on pageA won't be update.
If you use action=purge it will update the rendered output but the saved properties still won't be updated! You can see it on the Special:Browse page there will still be the old value.
Only when you edit and save the pageA the properties value will be updated.

Now imagine you have a pageC which will get a value depending on pageA which depends on pageB which perhaps depends on another pages value...

I use this e.g. for family names and other more complex stuff.

Example in the sandbox (pageA):
http://sandbox.semantic-mediawiki.org/index.php?title=Dynamic_attribute_purge_test

Change the attribute at (pageB):
http://sandbox.semantic-mediawiki.org/wiki/Dynamic_attribute_source

and then purge on pageA:
http://sandbox.semantic-mediawiki.org/index.php?title=Dynamic_attribute_purge_test&action=purge

So at least purging a page should update attributes. Even better would be an "internal link" or something like it is with templates. Whenever a page changes which you use in a inline query the page with the query should purge automatically when calling it the first time after the change on the other page.
Comment 1 Markus Krötzsch 2010-03-07 14:17:49 UTC
Purging is a MediaWiki operation for which SMW only adds a button for easier access, since SMW introduces more cases where purging the cache is needed. The purpose of purging a cache is to rebuild the view of a page which may have an outdated cache entry. It is not intended that a purging operation changes the database.

The problem that is described in this bug report only occurs when using results of inline queries (directly or indirectly) as values for properties. This is why SMW does not support or recommend doing this. Inline queries are meant to be used as dynamic views, not as intermediate computation steps in assigning annotations. If it were possible to do this easily and without blocking other features, SMW would explicitly generate an error when query results appear in places where they affect the value of a property.

The reasons for this design are rather fundamental. In fact, it is not hard to see that major computational problems would be created when endorsing query results in annotations. One could use other MediaWiki features such as ParserFunctions and templates to translate complex computations into a wiki page in such a way that the contents of a page recursively depends on itself. If SMW wanted to ensure that purging such a page would lead to a stable state of annotation (where storing the page again does not affect the stored values), then it would have to compute a fixed point of the wiki-encoded function. This fixed point might not exist in all cases, and it is a fundamental result of computer science that it is in general impossible to check whether or not such a fixed point exists by means of a computer program.

It is thus impossible to support query-based annotations properly: there would always be new situations that this support would not cover. Thus, there will never be any support for "dynamic annotations" in SMW.

A second major reason why SMW strongly discourages the use of "dynamic annotations" is that they provide a method of bypassing the history of a wiki. As long as annotations are based on the static contents of wiki pages, it is always possible to reconstruct the appearance of a given page at a given revision. By allowing annotations based on query results, the current value of the annotation can depend on the number of computation steps (times certain pages were stored/refreshed since their creation). Thus, a page might show a text that is not found anywhere in the database, or anywhere in the history.


P.S. If you still think that the "refresh" button should change the stored contents of a page, it should not be too hard to develop some extension that implements this behaviour. SMW will not provide for this functionality in order not to encourage such use of annotations.
Comment 2 Daniel A. R. Werner 2010-03-07 15:16:08 UTC
Ok you are right about those problems. A dynamic attribute using its own value recursively won’t be a pretty thing.
But still when clicking edit+save and then updating the attributes you have the same situation as you would have with a quick purge working this way, right?

Purge rebuilding attributes could also help with other problems. For example yesterday for any weird reason I can't tell all of my wiki pages suddenly lost their attribute. This was also when I recognized that purging a page doesn't rebuild attributes in the database so I had to save all those articles again instead of simply purging them. Enabling this feature and also clarifying that “dynamic attributes” aren’t supported might be a good thing after all. Disabling it via 


P.S. About your idea with the extension: Perhaps I will look into that if you think it’s a bad idea to implement it after all. My wiki uses "dynamic attributes" at some points. I think that they are great for avoiding redundancies and they allow you a new very abstract way of describing data’s in your wiki.

For the realization of the extension: I can use the hook ArticlePurge for that but how would I initiate the process for updating the data? Any ideas?
Comment 3 Daniel A. R. Werner 2010-03-07 15:18:54 UTC
> Enabling this feature and also clarifying that
> “dynamic attributes” aren’t supported might be a good thing after all.
> Disabling it via 
*Disabling it via confic variable in localsettings could still be possible if there's any reason why somebody won't use it.
Comment 4 Markus Krötzsch 2010-03-07 17:10:32 UTC
The function that you need for automatically rebuilding the data of a wiki (or for updating them in case of global changes that somehow did not cause automatic updates) can be found in Special:SMWAdmin. See http://semantic-mediawiki.org/wiki/SMW_repair for details.
Comment 5 Daniel A. R. Werner 2010-03-07 17:17:56 UTC
(In reply to comment #4)
> The function that you need for automatically rebuilding the data of a wiki (or
> for updating them in case of global changes that somehow did not cause
> automatic updates) can be found in Special:SMWAdmin. See
> http://semantic-mediawiki.org/wiki/SMW_repair for details.
Thanks but I know this feature and I tried to use it first but it takes ages even on my wiki with only some test pages to update everything or perhaps it didn't work properly. I didn't re-save some pages intentional to see when the SMW update will fix the problem but because it didn't happened until today I also re-saved the other pages.
Comment 6 Daniel A. R. Werner 2010-03-09 01:43:46 UTC
Thanks to the good SMW developer documentation it didn't took long for me to create an extension for semantic attribute purges.

You can find my extension "SemanticUpdateOnPurge" at http://www.mediawiki.org/wiki/Extension:SemanticUpdateOnPurge.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links