Last modified: 2012-06-07 21:24:20 UTC
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]]
2. I looked at smw_specialprops and noticed MySQL stored the set of properties
in a different order.
3. 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.
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.
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:
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.
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
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.