Some peanut-gallery comments (apologies if they repeat ideas already discussed, I haven't read the full thread):
>> > Chris Hostetter <[EMAIL PROTECTED]> wrote: >>>> as i said, i'd rather invert the use case set to find where "ordering >> >> isn't important" and change those to Maps It makes sense to use NamedLists only where they are truly needed so data that can be serialized to JSON as a hash always is, and doesn't get affected by json.nl. Of course we might stumble across cases where ordering isn't important, but multiple values with the same key is... While not the case for facet counts, if it ever came up that could be handled (in a different json.nl variant) by serializing with all same-keyed values collected into an Array, at the expense of strict ordering: [["DupKey", [Val1, Val3, Val4]], ["AnotherKey", Val2]] >On 1/24/07, Erik Hatcher <[EMAIL PROTECTED]> wrote: >>Faceting is the only thing I've come upon. After playing with this >>more and contemplating all the messages on this thread, I can't say >>that it's "broken", but telling solr to sort things and then when >>pulling them back out on the other end in seemingly random order it >>sure feels that way. Re-sorting on the client is the easiest >>solution and I've gone that route for now. I agree that having to do client-side sorting of a pre-sorted dataset is horrible. But the problem has nothing to do with SOLR, it is due to the limitations of JavaScript and thus JSON. The SOLR NamedList is a simple analog of the element-tree part of XML (no attributes or mixed content). This article gives a very thorough summary of the mappings between XML and JSON which can be applied to the NamedList->JSON issue as well: http://www.xml.com/lpt/a/1658 >>Having the facet_counts area output as an ordered list in all cases >>seems the most sensible to me, since it is unlikely that the facets >>would be accessed by key. Agreed. In JavaScript-land one can use array[array.indexOf(key,fromIndex)][1] to extract values by name, if so desired. I stumbled across a Ruby OrderedHash which looks to be an analog of NamedList: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/20551 I imagine it would be fairly simple to extend that OrderedHash to construct from a JSON-read array-of-pairs, especially since faceting should not emit duplicate keys. Yonik wrote: >I think a nice compromise between >efficiency and human readability might be to just alternate key,val in >the array: >['foo',10,'bar',20] >That would even allow representing a null key as a null in the array. I'm not sure there is an advantage to the current json.nl=arrarr, but it doesn't hurt to allow that to be specified as an alternate non-default format. >But I'm leaning on keeping the current format for XML for both >slightly better readability, and backward compatibility. ><lst> <int name="foo">10</int> <int name="bar">20</int> </lst> >As opposed to: ><arr> <str>foo</str> <int>10</int> <str>bar</str> <int>20</int> </arr> I agree re: not dumbing-down the XML serialization to match the lowest-common-denominator. - J.J.
