Hello Eric (and others) >> <snip> >> repeating the parameter: >> sort=field1,field2 desc,field3 >> but >> facet.field=field1&facet.field=field2 >> This is pretty confusing to first-hand users! :-) > > Yeah, it is confusing. But we have to be careful with order. I don't > believe you can rely on the order of same named request parameters (right?), > so sort needs to be a list where order matters. Whereas with facet.field, > order does not matter.
For date faceting, count missing the order doesn't matter either, and there it's given as a comma-separated list. I think it makes sense doing everything in comma (or space) separated lists, it's also "more" compatible with other programming languages: in many languages you can represent the GET variables as a dictionary, but of course GET variables can have repeated keys, that's where it breaks down. If instead of using multiple facet.field=... using one facet.fields=field1,field2 you'd get rid of the only place where it's used (well, ok, also in the date faceting). Using faceting.fields (plural) it could be backwards compatible. <snip> > Using the standard Solr/Lucene query parser, tag:(bass drum) will use the > operator specified in schema.xml, and it defaults to OR. >> is "+bass +drum" essentially the same as "bass AND drum" ? > > yes, exactly the same. Ahh, great. >> I'm working on a query/parameter builder in python. > > Cool deal. Might be worth collaborating with the pysolr project here: > <http://code.google.com/p/pysolr/> so as to not duplicate efforts. I've contacted Jacob (a famous man in the python/django community). Let's see how we can merge both projects. - bram -- http://freesound.iua.upf.edu http://www.smartelectronix.com http://www.musicdsp.org
