lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Mitchell <goodie...@gmail.com>
Subject Re: response issues with ruby and json
Date Sun, 23 Aug 2009 17:46:36 GMT
Thanks Yonik. Yeah the additional facet fields being added by the client do
make it a little more complicated.

Matt

On Sun, Aug 23, 2009 at 12:47 PM, Yonik Seeley
<yonik@lucidimagination.com>wrote:

> The spellcheck issue needs to be resolved.
>
> It doesn't seem like a good idea to access facet.fields by position
> though - there has never been any guarantee about the order that these
> come back in, and additional ones could be added as default parameters
> for example.
>
> -Yonik
> http://www.lucidimagination.com
>
>
>
> On Thu, Aug 20, 2009 at 10:54 PM, Matt Mitchell<goodieboy@gmail.com>
> wrote:
> > Hi,
> >
> > I was using the spellcheck component a while ago and noticed that parts
> of
> > the response are hashes, that use duplicate keys. This is the issue here:
> > http://issues.apache.org/jira/browse/SOLR-1071
> >
> > Also, the facet/facet_fields response is a hash, where the keys are field
> > names. This is mostly fine BUT, when eval'd in Ruby, the resulting key
> order
> > is not consistent; I think this is pretty normal for most languages. It
> > seems to me that an array of hashes would be more useful to preserve the
> > ordering? For example, we have an application that uses a custom handler
> > that specifies the facet fields. It'd be nice if the response ordering
> could
> > also be controlled in the solrconfig.xml
> >
> > I guess I have 2 questions:
> >
> > 1. Does anyone if the spellcheck component going to get updated so there
> are
> > not duplicate keys
> >
> > 2. How could we get the facet fields into arrays instead of hashes for
> the
> > ruby response writer? Should I submit a patch? Is this important to
> anyone
> > else? I guess the alternative is to use the xml response.
> >
> > Thanks,
> > Matt
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message