Problem with selecting pages with long SMW Property Values and LIKE


> Semantic MediaWiki 2.2.2 > Semantic Result Formats 2.3

Version 2.2.2 is no longer in active maintenance and therefore should not be avoided as reference when trying to modify code or cite code snippets.

> some text is only allowed for the first 70 characters or less, using the syntax ~*needle*, however I would like to extend this functionality.

To cover search in regards to longer text (or better text that is longer than the 70 char limit) or case insensitivity we have approached the problem differently in 2.5 [0] by relying on the full-text index for enabled dataTypes that are provided by the DB back-end.

> could not be reproduced on sandbox.semantic-mediawiki

The sandbox has the Fulltext search enabled where ~/!~ expressions do match conditions against the available full-text index (if you use format=debug then you should see that the SQL is generated using the MATCH ... AGAINST instead of LIKE).

> So far I do not see any drawback for this hack and I have not found any other points in the code where it is needed. If you think this could be useful for the project, please let me know. If you know of any reason why this is a bad idea

[0] cites several sources as to why using LIKE on a "long text" creates potential bottlenecks and is the reason why LIKE/NLIKE should only be considered on a limited VARCHAR field.

I think it is commendable that you dig into the code trying to find a workaround, unfortunately using an arbitrary `preg_replace` or `preg_match` approach is unlikely to be implemented due to SQL convention, support for different DB back-ends.

If you still think your approach should be examined more thoroughly then you may create a PR and run it against our test suite.

> only look directly in the hash only if the blob is null, like Extension:Semantic Drilldown

We consider this the wrong approach and may break on any schema change we apply to the SQLStore in future.

> 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

We try to find implementations that are hopefully stable and provide features without impacting existing functionality or risking the introduction of instabilities.

PS: Using [1] is a better place to discuss technical (code) changes.



04:09, 31 December 2016