| JeroenDeDauw | |
| Sep 18 2011, 2:06 PM |
| F8083: smwfail.png | |
| Nov 21 2014, 11:50 PM |
I'm getting the values of some SMW_SQL2_ constants in my wiki pages as interwiki links, making page "Foobar" link to "Smw-redi:Foobar", and sometimes making an otherwise empty result ":smw-border:" show up. I'm guessing the SQL store should be taking these out, but is failing to do so for some reason.
This blocks the 1.6.2 release.
Version: unspecified
Severity: major
Created attachment 9069
Screenshot of table format with several pages having incorrect links
Attached:
MediaWiki 1.19alpha (r97415)
PHP 5.3.5-1ubuntu7.2 (apache2handler)
MySQL 5.1.54-1ubuntu4
SMW trunk
Ok, I figured out why this was happening on one of my wikis, and not the other. The query in which I'm having the issue is
{{#ask:[[:+]]|?Modification date|format=table}}
while
{{#ask:[[Modification date::+]]|?Modification date|format=table}}
works fine.
Doing a full refresh of all data (I deleted my tables and did a reinstall) does not fix this, so it's not some data already messed up on my wiki.
Removing this as blocker; it was already in the previous releases.
Fixed in SVN now. The fix employs a post-query filtering to avoid such values to show up. The alternative would be to filter in the SQL query already, but this would add additional conditions to all queries. In most cases, this should not be needed since internal auxiliary entries should normally not have the data stored that would make them potential query results in any case. Mostly very general queries like namespace filtering could cause the issue, I think.
The post-query filtering has the one disadvantage that it leads to fewer results than expected in the affected cases. "Further results" will still work properly, but the actual list of results shown may not contain limit many entries if some are filtered. Since it seems to be a rare situation, I would prefer this over the performance-degrading approach of filtering this in SQL.