Page MenuHomePhabricator

Broken +index=x for records
Closed, ResolvedPublic


Author: kazink

I have recently updated from SMW 1.5.2 to 1.6, and this broke some of elements on my site. I use properties of type Record extensively, and I access them by single fields (+index=x parameter). Since the upgrade it stopped working. When I type for example:

{{#ask: [[My page]] | ?my record = }}

it will correctly display the values of all record fields, but when I do

{{#ask: [[My page]] | ?my record = | +index=1}}

it will not display anything. The record property has two fields: number and string, both are defined in "My page". The same happens when using #show query with +index.

Of course I have run database upgrade and data upgrade after installation (plus another data upgrade after adjusting records to the new style, just in case).

Unfortunately my wiki is private, so I cannot post a link to it, but I have tried reproducing the problem in the sandbox with partial success. The sandbox uses an alpha version of SMW 1.6, and it suffers even bigger problem from this setting. See the following pages:

After uncommenting the parts of code using +index, the page shows PHP Fatal error: Call to undefined method SMWDIContainer::getDVs() in /export/www/html/projects/SMW-Sandbox/extensions/SemanticMediaWiki/includes/storage/SMW_QueryResult.php on line 426

I will be happy to make the tests again when you upgrade the sandbox SMW to the stable version.

My software:
SMW: 1.6 (July 30, 2011)
MediaWiki: 1.17.0
PHP: 5.2.17
MySQL: 5.1.56
OS: Linux

Debug log does not show any errors, so does php, and format=debug gives the following output (the exact query is: {{#ask: [[Farm]] | ?progress_s = | +index=1 | format = debug}}):

Debug Output by SMWSQLStore2
Generated Wiki-Query


Query Metrics
SQL Query
SELECT DISTINCT t1.smw_title AS t,t1.smw_namespace AS ns FROM pqwsmw_ids AS t1 WHERE t1.smw_id='387' ORDER BY t1.smw_sortkey ASC LIMIT 51 OFFSET 0;
Auxilliary Tables Used
No auxilliary tables used.
Errors and Warnings

I have tried to disable all other extensions (except for Validator) in case of an interference, but it did not change anything.

Version: unspecified
Severity: critical
OS: Linux



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:57 PM
bzimport set Reference to bz30284.

kazink wrote:

Quick and dirty fis for the Record index problem


kazink wrote:

I found out where the problem is. The function loadContent() (includes/storage/SMW_QueryResult.php) has this comment near the 'index' processing code:

Print one component of a multi-valued string.
Known limitation: the printrequest still is of type _rec, so if printers check
// for this then they will not recognize that it returns some more concrete type.

It seems that the further processing does not recognize that this is a single value of a record, and tries to process it as a full record (which it isn't any more, because the single value has been extracted by the loadContent() function). This results in no value at all.

I attached a quick patch to work this problem around. Please note however, that this patch is only a workaround, NOT A SOLUTION. I suppose it may be utterly wrong when considered from the SMW architecture's point of view (I don't know SMW's code so much to provide a complete solution). And it simply may introduce other bugs, that I did not tested. It works as a quick and dirty fix - just to restore the normal functionality of my wiki, until the official fix is provided.

Markus, can you take on this one?

kazink wrote:

content hidden as private in Bugzilla

sumanah wrote:

Adding "patch" and "need-review" keywords to indicate patch awaits review.

Thanks, Kazimierz, for your analysis and suggestions. I have fixed the issue in r111267 and r111268. You were mostly right about the cause of the problem, but the main issue was in method getNextDataValue() where the (type record) property was used to create a datavalue object for the selected record field. The code there now finds and uses the correct property for each subvalue, even though this is not very efficient.

The comment about the "Known limitation" is in fact not relevant here. This limiation was always the same and only affects certain result printers (like timeline) that check the type of a printrequest to find out if a value can be used for a special purpose (in the case of timeline, a date-typed record field would not be accepted as a time to display, because the type says record). But this has always been the same.