Last modified: 2014-01-04 22:39:19 UTC
If you have a property set in a page in a custom namespace, the value does not get unset if the page is subsequently deleted. Example: A custom namespace is defined called PRIVATE define("NS_PRIVATE", 500); define("NS_PRIVATE_TALK", 501); $wgExtraNamespaces[NS_PRIVATE] = "Private"; $wgExtraNamespaces[NS_PRIVATE_TALK] = "Private_talk"; I have the namespace defined in $smwgNamespacesWithSemanticLinks Properties defined in pages in this namespace are set. For example: [[HasTitle::{{{Title|}}}]] If the page is then deleted, the property remains set with a red link to the deleted page. Correct behaviour should be the property is unset. Tested on MW 1.22, SMW 1.9 master
James, this seems to be related to stuff you did - any idea about this?
Neill, not going to elevate this to 1.9 blocker. I hope this issue gets resolved quickly and that it can go into a subsequent release, which I hope will happen not to far after 1.9.
Okay, fair enough Jeroen :) Hopefully this will get sorted as the problem was introduced in 1.8, so has been around a while now. Thanks!
(In reply to comment #1) > James, this seems to be related to stuff you did - any idea about this? Mmm, I don't recollect me working on this. Furthermore I don't really understand the problem. Taken into account the information given I was unable to reproduce an example nor find an appropriate unit test that would allow to create a false positive.
The code [1], [2] for page deletion does not distinguish between namespaces. [2] is already mentioning "///FIXME: if a property page is deleted, more pages may need to be updated by jobs!" which might be a reason as to why values being interpret as not being unset. [1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/Setup.php#L394 [2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/storage/SQLStore/SMW_SQLStore3_Writers.php#L53
Maybe you can test [1] to see if the issue reported above still occurs. You need to run the JobQueue because the clean-up job is expensive therefore relevant updates only happen after the Jobs are done. [1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/71
Thanks for the reply. Okay, I'll pull the master version and test.
Neill, this is not on master yet. It is currently on the branch named "bug" that is on our GitHub remote.
Neill, can you test the fix? It is still on the mentioned branch. If you can do this by tomorrow, the fix will be in the archive linked from the 1.9 rel announce email.
Hi. A quick test seems to indicate this fix works :) Thanks Guys.
Knowing the above fixed the apparent issue, I went ahead to remodel the implementation with some amendments. The removal of a subject from the Store is being moved into a `DeleteSubjectJob` and if necessary can be scheduled as `DeferredJob` (enables to run deletion as background job). Prior SMW 1.9, the subject deletion did not initiate any clean-up of possible associate subjects, the `smwgDeleteSubjectWithAssociatesRefresh` will allow to refresh entities that are connected to a deleted subject. A subject may be connected to a large group of associates, it is advisable that `smwgDeleteSubjectAsDeferredJob` is set TRUE in order to avoid any performance issues (or runtime errors) during the deletion process. In case the deletion is executed as `DeferredJob` it is suggested that the JobQueue is being run repeatedly within a narrow time frame to avoid an increased backlog. ### Legacy (default) setting $GLOBALS['smwgOnDeleteAction'] = array( 'smwgDeleteSubjectAsDeferredJob' => false, 'smwgDeleteSubjectWithAssociatesRefresh' => false, );
(In reply to comment #10) > Hi. > A quick test seems to indicate this fix works :) > > Thanks Guys. Please try to pull the new changes from [1] and adopt your LocalSettings with [2] in order to enable the refresh related entities. You may set `smwgDeleteSubjectAsDeferredJob` true or false depending on your local infrastructure. If `smwgDeleteSubjectAsDeferredJob` set true then only after the JobQueue is finished a subject will be removed from Store together with an update/refresh of related properties and subjects. [1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/tree/bug [2] $GLOBALS['smwgOnDeleteAction'] = array( 'smwgDeleteSubjectAsDeferredJob' => true, 'smwgDeleteSubjectWithAssociatesRefresh' => true );
Merged.
