{"action":"created","issue":{"url":"https://api.github.com/repos/s7eph4n/PurgePage/issues/1","repository_url":"https://api.github.com/repos/s7eph4n/PurgePage","labels_url":"https://api.github.com/repos/s7eph4n/PurgePage/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/s7eph4n/PurgePage/issues/1/comments","events_url":"https://api.github.com/repos/s7eph4n/PurgePage/issues/1/events","html_url":"https://github.com/s7eph4n/PurgePage/issues/1","id":164401596,"number":1,"title":"SMW and query subject dependencies","user":{"login":"mwjames","id":1245473,"avatar_url":"https://avatars.githubusercontent.com/u/1245473?v=3","gravatar_id":"","url":"https://api.github.com/users/mwjames","html_url":"https://github.com/mwjames","followers_url":"https://api.github.com/users/mwjames/followers","following_url":"https://api.github.com/users/mwjames/following{/other_user}","gists_url":"https://api.github.com/users/mwjames/gists{/gist_id}","starred_url":"https://api.github.com/users/mwjames/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mwjames/subscriptions","organizations_url":"https://api.github.com/users/mwjames/orgs","repos_url":"https://api.github.com/users/mwjames/repos","events_url":"https://api.github.com/users/mwjames/events{/privacy}","received_events_url":"https://api.github.com/users/mwjames/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-07-07T20:37:19Z","updated_at":"2016-07-08T09:27:11Z","closed_at":null,"body":"> This can be useful, when the content of Bar depends on Foo, e.g. when using a SemanticMediawiki query on Bar that contains data from Foo in the results.\r\n\r\nFYI\r\n\r\n`$GLOBALS['smwgEnabledQueryDependencyLinksStore'] = true;` setting should help automatically determine query subject dependencies and invalidated the parser cache on those pages and force a re-parse. To avoid stress on the back-end, I refrained from doing a `doPurge` and instead rely on `Title::invalidateCache` to reset the cache state.\r\n\r\n2.4 comes with an extra `smwgQueryDependencyAffiliatePropertyDetectionlist` [0].\r\n\r\n[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/83072ec22fa2319404c4d78bd7d51256a7d289d1/DefaultSettings.php#L894-L904"},"comment":{"url":"https://api.github.com/repos/s7eph4n/PurgePage/issues/comments/231315789","html_url":"https://github.com/s7eph4n/PurgePage/issues/1#issuecomment-231315789","issue_url":"https://api.github.com/repos/s7eph4n/PurgePage/issues/1","id":231315789,"user":{"login":"mwjames","id":1245473,"avatar_url":"https://avatars.githubusercontent.com/u/1245473?v=3","gravatar_id":"","url":"https://api.github.com/users/mwjames","html_url":"https://github.com/mwjames","followers_url":"https://api.github.com/users/mwjames/followers","following_url":"https://api.github.com/users/mwjames/following{/other_user}","gists_url":"https://api.github.com/users/mwjames/gists{/gist_id}","starred_url":"https://api.github.com/users/mwjames/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mwjames/subscriptions","organizations_url":"https://api.github.com/users/mwjames/orgs","repos_url":"https://api.github.com/users/mwjames/repos","events_url":"https://api.github.com/users/mwjames/events{/privacy}","received_events_url":"https://api.github.com/users/mwjames/received_events","type":"User","site_admin":false},"created_at":"2016-07-08T09:27:11Z","updated_at":"2016-07-08T09:27:11Z","body":"> What I still do not understand is how the DISPLAYTITLE of a page can change without changing the page? Up to now I thought \"subject\" and \"page\" were synonym, but maybe not?\r\n\r\nUnder normal circumstances the `QueryDependencyLinksStore` acts only on value changes that are part of a query description. Subjects are a special case, namely being the result of a query and if a subject (as object value) is deleted or nor longer part of a query result then an update is triggered.\r\n\r\nNow, if a subject (as page) that is part of the result list changes some if its values (we only care for the property not for the values itself as we only want to detect a change state) that are __not__ part of a query description then __no__ update is triggered because no notable change occurred in light of what the query is expected to represent. \r\n\r\nAn affiliate makes it an exception that even though the DISPLAYTITLE is not part of a query description, any modification to it will trigger an update, if the related subject is part of a query (as description or as result).\r\n\r\n`QueryDependencyLinksStore` does (simplified):\r\n\r\n* Page -> find `Query` -> resolve `Description` -> get ID's for properties, categories, concept, printrequests  -> `QueryResult` -> get ID's for all subjects of the result -> store QUERYID and ID's in the query links tables.\r\n* Page is modified -> `CompositePropertyTableDiffIterator` -> get list of changed ID's -> trigger job -> match list of changed ID's to query links table -> find matchable queries -> trigger iterative `ParserCachePurgeJob`\r\n\r\nFor example, you add a new page with `[[Some property::Foo]]` then the simple `QueryDependencyLinksStore` heuristic is not to waste precious computing on running a query trying to match an exact description (which would imply to account for limit/offset etc.) but instead it looks for all queries that contains `Some property` (happens in batch) and then fires a `Title::invalidateCache` on those subjects that have been linked to a query and contained a `Some property`.\r\n\r\nOf course, you will have some false positive because of the value condition (e.g.`Foo`) where a different query like `[[Some property::Bar]]` could or could not result in the same result list but remember, we only invalidate the cache of a page that contains a query not the query itself so the first user that visits the page will trigger the re-computation.\r\n\r\n`Title::invalidateCache` only updates `page_touched` while `doPurge` would trigger a complete null edit. Self-reference queries are a bit tricky (https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/1696).\r\n\r\n> Up to now I thought \"subject\" and \"page\" were synonym, but maybe not?\r\n\r\nIt depends on the context, whether the subject in itself only represents an object value or is an entity.\r\n"}}
{"actor":{"display_login":"mwjames"}}