Last modified: 2014-11-20 21:48:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34955, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32955 - #ask query parsing fails when = character occurs in query string
#ask query parsing fails when = character occurs in query string
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 36351 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-10 21:44 UTC by badon
Modified: 2014-11-20 21:48 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description badon 2011-12-10 21:44:40 UTC
Type URL can:

Define a property:

* [[URL::https://www.google.com/search?q=semantic+mediawiki]]

Be queried for the property:

* {{#show: Some page | ?URL}}
* {{#ask: [[Some page]] | ?URL}}

But cannot be queried by property if the URL has an equals sign in it:

* {{#ask: [[URL::https://www.google.com/search?q=semantic+mediawiki]] | ? | ?URL}}
* {{#ask: [[URL::=]] | ? | ?URL | link=none}}

It will produce the incorrect error "Some subquery has no valid condition.".

This was tested in SMW 1.6. I'm not sure if this bug still exists in current development versions (I can't use SMW 1.6.1 because image queries do not work well).
Comment 1 badon 2012-01-09 05:27:25 UTC
This bug has gotten worse in SMW 1.7, and will now cause the page to fail to display completely. I have made a demo here (login with Demo/test):

http://www.coincompendium.com/w/index.php/Sandbox/Bug_32955

I have also increased this to "critical", since it disrupts the page display now, instead of merely producing erroneous queries.
Comment 2 badon 2012-01-09 05:30:43 UTC
I also updated the demo to be compatible with the breaking changes in the query format done in 1.7:

http://wikimedia.7.n6.nabble.com/Semantic-Result-Formats-1-7-released-tp2799845p3504612.html
Comment 3 badon 2012-02-08 02:39:37 UTC
I tested this in SMW 1.7.0.2 and the bug demo still works the same as in 1.7.
Comment 4 badon 2012-02-18 06:05:40 UTC
I tried to work around this problem with type Text, but it seems text cannot be queried by property:

http://semantic-mediawiki.org/wiki/Help:Type_Text

I also tried type String, but that is limited to only 255 characters. Many URLs are often much longer. 

It appears the only workaround is to break up URLs into pieces and query for each piece. That will take a lot of semantic data overhead and substantial amounts of code, and I have decided not to do it.

I will keep thinking to see if I can come up with a workaround until this is fixed. I just tested SMW 1.7.1 Beta/RC1 and discovered this bug has not been fixed in the upcoming release.
Comment 5 badon 2012-02-18 06:34:05 UTC
It looks like in 1.7.x it is the page layout that is broken. I'm not sure how that happened.
Comment 6 Markus Krötzsch 2012-02-19 11:18:25 UTC
(In reply to comment #4)
> I tried to work around this problem with type Text, but it seems text cannot be
> queried by property:
> 
> http://semantic-mediawiki.org/wiki/Help:Type_Text
> 
> I also tried type String, but that is limited to only 255 characters. Many URLs
> are often much longer. 
> 

This will be an independent problem for you then. The SMW database backend can only store 255 characters for any data value that is not Text or Code. String reports a problem, but URL has the same limitation (and may not report it). This is independent from this bug, but gave me an idea on how to improve the handling of long strings in general; I filed this as bug 34511.
Comment 7 badon 2012-02-19 20:37:11 UTC
Thanks for catching and reporting that issue for me, I was not aware of it yet. 

Is bug 34511 a blocker for this bug? I don't think it is, since this bug is only about one problematic "=" character. But, even if that is fixed, correct behavior won't be reliable until bug 34511 is fixed. And, maybe the implementation details of how bug 34511 is fixed will affect how this one is fixed.
Comment 8 Markus Krötzsch 2012-02-20 14:07:10 UTC
Bug 34511 is not related to this bug. They are completely independent. The bug reported here is related to parsing input of the #ask function; bug 34511 is related to the database API. They should not affect each other at all.

The problem in the given bug is that "=" is a special character in #ask for denoting parameter values. There needs to be some mechanism to prevent SMW mistaking your input for a parameter assignment.

I do not know how and why #ask queries with this behaviour have a negative effect on your page layout, but if they do then this should not be related to the problem with =. Probably similar layout problems occur for all queries, or for all queries that have some error messages. The = bug in turn should occur for all data values that include =, not just for URLs. I will update the title accordingly.
Comment 9 badon 2012-02-20 19:07:14 UTC
Actually, yes, I have noticed layout problems in other queries. But, I had thought it was a problem with my code, not in SMW. Now that I know that it may be a valid bug in SMW, I'll test the cases I have where I'm experiencing it to see if I can isolate a demo for a bug report. 

Once again, thanks for so generously sharing your insights. It is much appreciated, and very helpful for me in my bug testing efforts. I wish everyone were so considerate as you are.
Comment 10 Markus Krötzsch 2012-04-30 13:16:48 UTC
*** Bug 36351 has been marked as a duplicate of this bug. ***
Comment 11 [[kgh]] 2014-11-20 21:07:37 UTC
Fixed with pull request 640 [1]. Thus closing as RESOLVED FIXED.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/640

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links