SQLStore / Unconditional query includes deleted subjects (pages)

[kappagithub]

As reported on https://semantic-mediawiki.org/wiki/Help_talk:Selecting_pages#Filtering_deleted_pages_seems_not_to_work_with_SQLStore3_as_well_583 the problem of deleted pages showing up as query results still persists in SMW 2.0.
I have set up a test wiki where you can see an example: https://publicwiki-01.fraunhofer.de/1.23/Test-SMW (the wiki remains there until it will be filled with spam). Adding the "hotfix" from #566 (adding three lines to SPARQLStore::changeTitle) did not help. In the example pages 3 and 4 have been deleted.

[mwjames]

Thanks for the example.

Some preliminary notes:

Adding the "hotfix" from #566 (adding three lines to SPARQLStore::changeTitle) did not help.

Applying the patch makes only sense if you are using the SPARQLStore the changes have no influence on the SQLStore

Your ask query actually means "give me all pages in namespace Test" because Test: is registered as separate NS.

{{#ask: [[Test:+]]
| ?attribute1
| ?attribute2
}}

Since it is an unconditional query, it returns all possible pages even those deleted because the SQLStore doesn't delete a subject entry it sets it to be empty [0] leaving the subject (Page3/Page4) to remain in the smw_object_ids table. See also note [1], which states that "TODO: Possibly delete ID here (at least for non-properties/categories, if not used in any place in rels2)"

Above behaviour is codified from the very beginning of (SQLStore2 and SQLStore3 == SQLStore ) therefore it is unrelated to SMW 2.0.

See also, refs #498.

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/storage/SQLStore/SMW_SQLStore3_Writers.php#L58

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/storage/SQLStore/SMW_SQLStore3_Writers.php#L89

@kghbln FYI

[kappagithub]

Great, thank you very much for your fast reply and your detailed analysis.
This provides at least a very good workaround
I have added a condition to the query, and now the deleted pages do not
show up any longer.

Since I assume your answer to be interesting for other people as well, I
left a note on the discussion page
https://semantic-mediawiki.org/wiki/Help_talk:Selecting_pages#Filtering_deleted_pages_seems_not_to_work_with_SQLStore3_as_well_583

Thank you very much
best wishes

Am 09.01.2015 um 18:18 schrieb mwjames:

Thanks for the example.

Some preliminary notes:

Adding the "hotfix" from #566
<https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/566> (adding
three lines to SPARQLStore::changeTitle) did not help.

Applying the patch makes only sense if you are using the |SPARQLStore|
the changes have no influence on the |SQLStore|

Your ask query actually means "give me all pages in namespace Test"
because |Test:| is registered as separate NS.

|{{#ask: [[Test:+]]
| ?attribute1
| ?attribute2
}}
|

Since it is an unconditional query, it returns all possible pages even
those deleted because the |SQLStore| doesn't delete a subject entry it
sets it to be empty [0] leaving the subject (Page3/Page4) to remain in
the |smw_object_ids| table. See also note [1], which states that
"TODO: Possibly delete ID here (at least for
non-properties/categories, if not used in any place in rels2)"

Above behaviour is codified from the very beginning of (|SQLStore2|
and |SQLStore3|) therefore it is unrelated to SMW 2.0.

[0]
https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/storage/SQLStore/SMW_SQLStore3_Writers.php#L58

[1]
https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/storage/SQLStore/SMW_SQLStore3_Writers.php#L89

@kghbln https://github.com/kghbln FYI

—
Reply to this email directly or view it on GitHub
#701 (comment).

PD Dr. Karin Haenelt
Fraunhofer Gesellschaft e.V. (FhG)
Fraunhoferstraße 5
64283 Darmstadt
Germany

Tel ++49-(0)6151-155567

kontext.fraunhofer.de/haenelt

[mwjames]

This was solved with #1100, meaning that deleted subjects are no longer displayed for unconditional namespace queries.

{{#ask: [[Help:+]]
 | ?Has some property
}}

@kghbln FYI