On 29/06/11 16:39, zehetner wrote: > Hi, > > does somebody know if SMW 1.6 still keeps for multivalue (record type) > properties the information about the order of the single values somewhere > in the database or if that got lost? > > Up to now in table atts2 the field p_id allowed to identify (with the help > of the smw_iw=':smw-intprop' values from table ids) the original order of > the values of value_xsd withing such a property. > > +---------+------+-----------+------------+-----------+ > | s_id | p_id | value_xsd | value_unit | value_num | > +---------+------+-----------+------------+-----------+ > | 3950215 | 24 | Source1 | | 0 | > | 3993424 | 23 | Name3 | | 0 | > | 3950216 | 23 | Name2 | | 0 | > | 3950216 | 24 | Source2 | | 0 | > | 3950215 | 23 | Name1 | | 0 | > | 3993425 | 24 | Source4 | | 0 | > +---------+------+-----------+------------+-----------+ > > So in this case it was e.g. [[Prop::Name1;Source1]] and [[Prop::Name3;?]] > and [[Prop::?;Source4]] etc. > > Now with SMW 1.6 the field p_id contains a smw_id value which points to > the property type of the record field in table ids > > +---------+---------+-----------+-----------+ > | s_id | p_id | value_xsd | value_num | > +---------+---------+-----------+-----------+ > | 3912158 | 3993483 | Source4 | 0 | > | 3904473 | 3993483 | Source2 | 0 | > | 3904473 | 3993483 | Name2 | 0 | > | 3904472 | 3993483 | Name1 | 0 | > | 3904472 | 3993483 | Source1 | 0 | > | 3904474 | 3993483 | Name3 | 0 | > +---------+---------+-----------+-----------+ > > So from this info one can not see anymore if the property was e.g. > [[Prop::Name1;Source1]] or [[Prop::Source1;Name1]] > and [[Prop::Name3;?]] or [[Prop::?;Name3]] etc. > > Is the order now maybe stored somewhere else in the DB tables? > Would be most grateful if someone could give me a hint.
On the data level, records are "containers" and store data without any order. Containers are basically like "Factboxes" in SMW: sets of property-value pairs. Type:Record used to use special properties "_1", "_2", ... to encode the order, but the order was still unknown to the store (it was just the higher level of the Record that interpreted these special properties as ordinal). In the current code, the declaration of Type:Record still uses an ordered list of properties, so the order is known on this level. When Records are displayed or queried, this information is still available (as before, but not with fixed property names "_1", "_2", ...). As before, the order is not considered to be part of the data. [Potential weakness of allowing arbitrary property names instead of _1, _2, ...: they will not work well when the same property is used more than once. This also affects the use of "type properties" like "String" that are now supported. In general, Record should become part of an extended set of container datatypes that provide more features than just storing finite lists of properties -- future improvements on this level should be part of this effort.] A recent change in SVN (Jeroen?) has moved the creation of value lists to the container dataitem of SMW which (as explained above) cannot possibly reconstruct the order. So code relying on this method will confuse the order now. This needs to be fixed by moving the list creation back into the datavalue code. Regards, Markus ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
