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]] properties 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, http://www.mail-archive.com/semediawiki-user@lists.sourceforge.net/msg00144.html 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 values). 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 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.
