Thread:Help talk:Selecting pages/Problem with selecting pages with long SMW Property Values and LIKE

First and foremost I know that searching pages with a semantic property that contains some text is only allowed for the first 70 characters or less, using the syntax Property_name::~*needle*, however I would like to extend this functionality.

The example I will show you in this topic could not be reproduced on sandbox.semantic-mediawiki or similar wikis, probably due to different versions of the platform, I will give you my specifics:

MediaWiki	1.25.1

PHP	5.3.3 (apache2handler)

MySQL	5.1.73

Semantic MediaWiki   2.2.2

Semantic Result Formats   2.3

I will show you screenshots generated from my wiki/DB

Let's take 2 different pages, both part of the same category (Impresa), created with the same form etc. One, Very Short Page has a very short value for the Comment property, the other, Entity with a very long labeltest1234567890, has a very long value for the Comment property as shown in the pictures below

Very Short Page: http://imgur.com/aQBu4nY

The other one: http://imgur.com/TtTymSl

Now if I want to select these pages I could see that there is a common string in their comment, "This is a page", so i could think about doing an ask on Comment::~*is a page*

The result only includes Very Short Page because it's the only one with that substring in its first characters as shown here: http://imgur.com/Wd64Njs

Thanks to the debug result format I can see the SQL query in which the ask was translated, running the query directly on the database has the same result: http://imgur.com/rxTFi0r

But there is a problem with this: If I call Comment::~*c9b45d* I would expect to hit no results, as no pages in my wiki has that string in the Comment property, however I do hit the Entity with a very long... because its hashed content contains that string, this leads to a wrong result: http://imgur.com/ULYlQwz

While you might think this is a stupid search, in Italian there are words that can be formed with just letters from "a" to "f" such as "bebe", "caffe" etc. so it's possible to hit hashed properties while looking for something else entirely, these are false positive matches that I absolutely do not want.

The solution to both problems (false negatives while looking for "is a page" and false positives while looking for a gibberish hexadecimal string) is to look in the blob when it is not null and only look directly in the hash only if the blob is null, like Extension:Semantic Drilldown does, such as: http://imgur.com/3wICFp0

I would like to know if it is possible to hotfix this functionality in the core SemanticMediaWiki implementation or why this is a bad idea, I would appreciate guidance on how to use this workaround for all ask queries myself if needed, or any other workaround that would get me the same result.

Thanks