Last modified: 2011-06-12 13:59:11 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 T31159, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29159 - "Has default form" not handled correctly in SMW 1.6
"Has default form" not handled correctly in SMW 1.6
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Unprioritized critical (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-26 22:14 UTC by Yaron Koren
Modified: 2011-06-12 13:59 UTC (History)
2 users (show)

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


Attachments

Description Yaron Koren 2011-05-26 22:14:32 UTC
I submitted some bugs before, relating to SMW 1.6, that are now fixed, but I think this one is different. You can clearly see the problem here:

http://discoursedb.org/wiki/Special:Browse/Category:Authors

"Has filter" is handled correctly, but "Has default form" displays the error '
"Form:" cannot be used as a page name in this wiki.' I think the issue is somehow due to the fact that "Has default form" is defined to point to a specific namespace; but I don't know more than that.
Comment 1 Markus Krötzsch 2011-05-27 09:15:06 UTC
Acknowledged. This is the typing issue that I mentioned earlier. The datatype that has default form uses is no longer working as before, and data is not retrieved successfully. I guess what we see is simply the result of retrieving an empty string as data, and trying to use it as a title text with namespace Form:.

A similar problem did occur with "has type" and a new way of storing it is introduced in SMW 1.6. Basically, this is due to an internal incompatibility between the special property table in SMQSQLStore2 (this stores plain string values), and the data item that all wiki page properties now use (which needs to store all the fields of a wiki page). I will think about a solution for the SF types as well.
Comment 2 Markus Krötzsch 2011-06-12 13:07:03 UTC
The problem should be fixed in the current SVN. Ideally, all existing data should immediately become accessible after update, even on pages that have been modified since the problem occurred.
Comment 3 Yaron Koren 2011-06-12 13:56:03 UTC
Yay, it works!! I believe this was the last major step before SF 2.2 can be released.
Comment 4 MWJames 2011-06-12 13:59:11 UTC
We tested it for 1.17beta, and it works their is well.

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


Navigation
Links