On 1/24/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Jan 22, 2007, at 6:14 PM, Yonik Seeley wrote:
> 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
>
> That might be a *lot* of changes...
> What's currently broken, just faceting or anything else?
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 plan on digging into the JSON option a bit and seeing if order is
preserved, though I doubt it would be any difference since it will
surely parse back into a Hash by default. Though the json.nl.arr=arr
would surely preserve order, though that changes the access to things
all over the place on the client.
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.
For JSON and friends, I agree. 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.
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>
-Yonik
