: 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
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 sen
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 cha
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 e
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?
-Yonik
: On the whole NamedList thing, let me put it another way.
: Should one be able to get to the response header via
: a["responseHeader"]
: OR
: a[0]
:
: If you can only have one, the former is clearly superior.
: That means we either have to
: 1) mark the base NamedList as "ok to render as someth
: > Ugh ... please no ... the "List" in "NamedList" is what indicates that
: > order is a factor (it's what distinguishes a NamedList from a hypothetical
: > MultiValueMap")
:
: But we also use it when order doesn't totally matter, but it's still nice.
I agree ... a NamedList is nice when you wan
On 1/22/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
For the record, I predicted this problem would come up...
http://www.nabble.com/JSON-output-support-tf1915406.html#a5247622
Yes, you were responding to my email where I highlighted that as a
potential future problem ;-P
On the whole Name
On 1/22/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
For the record, I predicted this problem would come up...
http://www.nabble.com/JSON-output-support-tf1915406.html#a5247622
: We could introduce some new types to tell the output handlers just how
: important it is to maintain order, so al
For the record, I predicted this problem would come up...
http://www.nabble.com/JSON-output-support-tf1915406.html#a5247622
: We could introduce some new types to tell the output handlers just how
: important it is to maintain order, so all named lists don't get
: treated the same.
:
: Example:
On 1/22/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
An efficient representation using arrays would be two separate arrays:
one for terms, one for counts.
terms=["foo","bar","baz"]
counts=[30,20,10]
But you loose easy random access lookup, and for a sufficiently large
list, you loose the ability
On 1/22/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
But isn't this considered a bug in the data structure used to write
out the facets?
Not for JSON I think... that's a wire format, and the order is what
you see on the wire.
It can be a problem preserving order, depending on the client.
The pr
On Jan 21, 2007, at 11:54 PM, Yonik Seeley wrote:
On 1/21/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
In the built-in simple faceting, I get a Ruby response like this:
'facet_counts'=>{
'facet_queries'=>{},
'facet_fields'=>{
'subject_genre_facet'=>{
'Biography.'=>2605,
On 1/21/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
Options:
- Resort yourself (for this specific case), it's probably going to
be faster than having eval() create a new hash object for each anyway.
- Is there any place to hook into ruby's parser and create a map
that preserves it's order? I
On 1/21/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
In the built-in simple faceting, I get a Ruby response like this:
'facet_counts'=>{
'facet_queries'=>{},
'facet_fields'=>{
'subject_genre_facet'=>{
'Biography.'=>2605,
'Congresses.'=>1837,
'Bibliograph
I presume this same dilemma is in the Python/JSON format too? In
XML, the has the right semantics, and a parser would easily be
able to deal with it in order:
The JSON writer has &json.nl=arrarr that spits the results out as an
array of arrays...
Its uglier, but it does keep order
In the built-in simple faceting, I get a Ruby response like this:
'facet_counts'=>{
'facet_queries'=>{},
'facet_fields'=>{
'subject_genre_facet'=>{
'Biography.'=>2605,
'Congresses.'=>1837,
'Bibliography.'=>672,
'Exhibitions.'=>642,
'Period
17 matches
Mail list logo
