Wikimedia Bugzilla is closed!

(In reply to comment #0)
> AddPropertyObjectValue throws MySQL errors (column not found blob etc.) while

If you do report an issue [0], please report the exact error (with stack trace, error message etc. [1]) and the version used (MW, PHP, SMW etc. see [2]) otherwise this issue is insufficient in its description and will most likely be closed.

> using custom PHP-driven properties in SMW 1.8.x. This doesn't happen in
> 1.7.x.

If you do use custom development, please ensure that your procedures conform with the environment necessary to execute MW/SMW-core functions.

[0] http://www.semantic-mediawiki.org/wiki/Help:Reporting_bugs

[1] http://www.semantic-mediawiki.org/wiki/Stack_trace

[2] http://www.semantic-mediawiki.org/wiki/Special:Version

In this case I had to downgrade to SMW 1.7.1 which cost me alot of time. Then I made this bug report. I can't reproduce the exact message from shell (I triggered it on shell with SMW_refreshData.php) because I m now using an older version which all its dependencies. But I'm sure the SMW-team knows what happens... there is obviosly a inconsistency between the database structure and the code. "column not found" is a standard MySQL-Message. This bug will affect other extensions too, like Semantic Extra Special Properties which currently relies on SMW 1.7. So I'm sure someone will fix it :-).

(In reply to comment #2)
> version which all its dependencies. But I'm sure the SMW-team knows what
> happens... there is obviosly a inconsistency between the database structure

This is a misconception, if the error is unknown (it also means if the description is insufficient, nothing is obvious no matter how trivial it seems) no one will and can spent time on this as it is not clear how to reproduce the error and test it against a change to verify that the error is gone.

Wait a minute, I will change the complete system to show you the original message.

For your convenience

minor:
<code>
<b>Deprecated</b>:  Use of User::editToken was deprecated in MediaWiki 1.19. [Called from SFFormEdit::printForm in Q:\flampp\htdocs\schnatzikutzki\extensions\SemanticForms\specials\SF_FormEdit.php at line 323] in <b>Q:\flampp\htdocs\schnatzikutzki\includes\debug\Debug.php</b> on line <b>282</b>
</code>

major from the MW-GUI while saving the edit form:

INSERT INTO `smw_di_blob` (s_id,p_id,o_blob,o_hash) VALUES ('145','144',NULL,'Hans'),('145','150','156'),('145','152',NULL,'Hans')
 from within function "SMW::writePropertyTableRowUpdates-insert-smw_di_blob". Database returned error "1136: Column count doesn't match value count at row 2 (localhost)".

major from shell (triggered by SMW_refreshData.php):

A database query syntax error has occurred.
The last attempted database query was:
"INSERT  INTO `smw_di_blob` (s_id,p_id,o_id) VALUES ('51','150','151'),('51','152
from within function "SMW::writePropertyTableRowUpdates-insert-smw_di_blob".
Database returned error "1054: Unknown column 'o_id' in 'field list' (localhost)"

I use the same code as the guys in Semantic Extra Special Properties in the propper handler:

<code>

SMWDIProperty::registerProperty('___ABCED', '_str','ABC Document Edited By',true);
        SMWDIProperty::registerPropertyAlias('___SDWED', 'ABC_Document_Edited_By');

[...]

        $user = $wgUser->getName();  
        $property = new SMWDIProperty('___SDWED');
        $dataItem = new SMWDIString($user);
        $data->addPropertyObjectValue($property, $dataItem);

</code>

For this reproduction I switched to MW 1.20.2 + SMW 1.8.2

By the way could you please release my other bug reports?

(In reply to comment #5)
> <b>Deprecated</b>:  Use of User::editToken was deprecated in MediaWiki 1.19.
> [Called from SFFormEdit::printForm in
> Q:
> \flampp\htdocs\schnatzikutzki\extensions\SemanticForms\specials\SF_FormEdit.
> php
> at line 323] in
> <b>Q:\flampp\htdocs\schnatzikutzki\includes\debug\Debug.php</b>
> on line <b>282</b>
> </code>
No relevant to the case.
 
> I use the same code as the guys in Semantic Extra Special Properties in the
> propper handler:
> 
> <code>
> 
> SMWDIProperty::registerProperty('___ABCED', '_str','ABC Document Edited
> By',true);

That this means that the error is thrown because you wrote your own function? Since addPropertyObjectValue (as part of the SMWSemanticData Class) is used with in SMW/SRF core without issues and no reproducible error, I can't see why this is an error of SMW. For help on how to use addPropertyObjectValue, please use [1]. (Bugzilla shouldn't not be used to seek developer advice on self developed implementations.)

[1] http://semantic-mediawiki.org/doc/classSMWSemanticData.html

Ok If this is not a bug. Then its a lack of documentation. The class reference doesnt show up any relevant changes. So we can't write SMW-Data with PHP anymore.

(In reply to comment #7)
> Ok If this is not a bug. Then its a lack of documentation. The class
> reference
Lack of documentation? Please keep in mind SMW is a volunteer project and it can only grow with participation. If you find document is insufficient, help to improve (open a new chapter and if a core-developer finds the time he/she might comment on it, please don't expect them to do all the work)

> doesnt show up any relevant changes. So we can't write SMW-Data with PHP
> anymore.
Just because is doesn't seemed obvious, does not make it nullified. See [1] how to use addPropertyObjectValue in a different context (is used in SMW 1.9 but is the same as in SMW 1.8)

[1] http://semantic-mediawiki.org/doc/SubobjectParser_8php_source.html#l00034

Tried to post it to the mailinglist. The message was truncated and finally trashed.

Yes OK, but the question is how to port this to a 
$wgHooks['SMWStore::updateDataBefore'][] - handler

The documentation says this:

http://www.semantic-mediawiki.org/wiki/SMW_Hooks/SMWStore::updateDataBefore

...unfortunately its not enough to get creative ;-).

OK, just for clearing. It was a type problem '_wpg' vs. '_str' which causes this mysql errors. And indeed I never would expect such side effects. So it was no technical bug. It was a missunderstanding. I feel so sorry now ;-)...but I also spent two days with this issues.