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 <yo...@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<goodie...@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 > > >
