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!

(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

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.

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.