Page MenuHomePhabricator

new datatype which allows to define a list of possible answers plus some extra features
Closed, DeclinedPublic


Author: info

In MySQL at least, the set of [[Allows value:=xyz]] special properties is not
necessarily stored in smw_specialprops in the same order as they appear on the
attribute's page. Thus they aren't retrieved in the same order, so values of
that attribute get a semi-random integer value in smw_attributes. This means
queries that sort on an enumerated attribute or query for attribute values
greater or less than an enumerated value don't work.

Steps to reproduce:

  1. I edited an existing attribute and gave it a new set of [[Allows value]]


  1. I looked at smw_specialprops and noticed MySQL stored the set of properties

in a different order.

  1. I queried on this attribute with a sort by it and confirmed that articles

appeared in the wrong order.

I think the fix is
a) in addSpecialValue() increment a per special-property sequence number for
each value of a special property that's an attribute,
b) store this in a new sequence column in smw_specialprops
c) when retrieving special properties order by this sequence column.
But it's not that easy. Currently addSpecialValue() doesn't simply append each
[[Allows value]] property value to an array, it creates a hash of special
properties indexed by each value's getHash() function.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:37 PM
bzimport set Reference to bz9750.

Can't we just order enumerated values alphabetically (like other strings)?

I guess you think of use cases like "good", "medium", and "bad" (in that order),
but is this needed so desperately that we should do so much work (and inclusion
of special code in SMW) to get it? Currently no storage access ensures any
ordering (other than the ones that sort according to the "natural" order of the
results), and changing this (even if we could implement it somehow) for selected
special properties seems problematic. The only clean way (API-wise) would be to
support n-ary special properties, which allow an optional sort key in addition
to the text.

But even in the above case, one could always use "1 (good)", "2 (medium)", and
"3 (bad)" or something similar to get the deisred order from the alphabet.

info wrote:

An alphabetical sort wouldn't let you query for [[quality:=>2 (medium)]].

It was cool that ordered enumeration worked in my prototype implementation, but
I agree user needs should drive. We could ask for feedback, meanwhile I marked
this bug low-priority.

Ittay Dror on semediawiki-user asked for it:

"i want then to be able to list all components for a given version (something

like [[product_version:=<1.3]]). version names can be anything (e.g. 'xp')."

but he (she?) rolled his own code anyway,
He put an explicit sequence number in the special property to ensure ordering:

[[Allows value:=Blocker=7]]

This feature could be added to current code (or could be a second
Type:OrderedEnum implementation, but I think you're not keen on a multitude of
types -- no type boolean ;-) ).

I had a few other "near misses" where a guaranteed special property order would
have been useful; IIRC gluing two string properties together to avoid string
length limitations, and picking the first unit conversion factor as the primary
one. The needs went away during implementation.

An alphabetical sort wouldn't let you query for [[quality:=>2 (medium)]].

I think it should. If it does not work this way, I can fix this without much
work. As long as alphabetical order is OK this should be the expected behaviour.
The problem is just to attach additional ordering information to data values
(which currently are just values, API-wise). The API-bottelneck is: when reading
special properties from the store, how do I get the order (in addition to the

Your solution was to store all possible values as an ordered, comma-seperated
list as one entry. But this also has some drawbacks (e.g. the combined length of
all values is restricted). Maybe we could use some hack to store value AND
sortkey in one field (e.g. using syntax "2::Medium" where the value is "Medium"
and the key is "2"). I suppose I could live with that, though some special
processing will be needed as part of the Factbox and when reading possible
values in SMWDatatype.

Another question is: if the order emerges implicitly from the input order of
facts, will the users be confused by this order? Maybe they actually expect
alphabetical order as a default.

alan.trick wrote:

My personally opinion is that in many cases were order could be significant,
it's not alphabetical (i.e. High, Normal, Low). In the cases where it is
alphabetical, they could be placed in alphabetical order manually, or there
could be another data type. Ordering it alphabetically would restrict the
possibilities. Sticking numerical indexes in front works, but it's ugly and adds
useless junk.

That said, I think either way is better than the current method (or lack of).
Any clue as to when this is getting worked on. I don't know too much about about
SMW, but I might try checking out the svn code and working on it myself. It
would help if I could get some guidance though, is there an IRC channel for SMW?

I tried using Ittay's code, and I got part of it working (there was some old API
stuff in there), but it wouldn't insert the values into the smw_attributes table
(although they displayed properly on the page).

There is currently no more Type:Enumeration, but instead "allows value" works for all types (and Enumeration is just a String then). Since types already have their built-in order, this bug is no longer a bug. It is, however, a feature request for having a new type which allows you to define a list of possible answers plus some extra features as wished for in the mentioned special use cases. I imagine that these would be:

  • It must be possible to define the order of the possible values.
  • It should be possible to define aliases for each value.
  • It would be nice to associate an "icon" (image) to each value that can be used e.g. in query generated tables.

This might rather be a new kind of simple custom datatype definition, than a set of special properties for some property. We will keep this in mind.

@mkroetzsch, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

No, I don't think I will work on this anytime soon. Thanks for cleaning up :-)

As a workaround for people who need this, I would suggest the use of type wikipage (not string), so that you have a page for "High", "Normal" and "Low" (maybe you want to call it "High pressure" or something like this to be more specific). Then you can define a MediaWiki sortkey for these pages to control ordering in query results.

Qgil lowered the priority of this task from Medium to Lowest.
Qgil set Security to None.

Ok, assignee and priority reset accordingly.

No, I don't think I will work on this anytime soon. Thanks for cleaning up :-)

You can heal cleaning up too. :) Currently you have 68 tasks assigned to you, the majority of them with "Normal" priority, which looks unrealistic. Our recommendation is that you should have a task assigned to yourself only when you are prepared to work on it.

Aklapper added a subscriber: Aklapper.

The Semantic MediaWiki developers requested in to move their task tracking to and to close remaining tasks in Wikimedia Phabricator. If you still face the problem reported in this task in a supported version of SMW, please feel free to transfer your report to . We are sorry for the inconvenience.