Page MenuHomePhabricator

Properties do not unset on pages in custom namespaces
Closed, ResolvedPublic

Description

Author: mitchell_neill

Description:
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


Version: master
Severity: major

Details

Reference
bz59204

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:15 AM
bzimport set Reference to bz59204.
bzimport created this task.Jan 2 2014, 11:57 AM

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.

mitchell_neill wrote:

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!

Unknown Object (User) added a comment.Jan 3 2014, 11:52 AM

(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.

Unknown Object (User) added a comment.Jan 3 2014, 12:33 PM

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

Unknown Object (User) added a comment.Jan 3 2014, 1:45 PM

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

mitchell_neill wrote:

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.

mitchell_neill wrote:

Hi.
A quick test seems to indicate this fix works :)

Thanks Guys.

Unknown Object (User) added a comment.Jan 4 2014, 3:18 PM

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,
);

Unknown Object (User) added a comment.Jan 4 2014, 3:24 PM

(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

);