I don't think of queries as inherently flat in the way HTTP request parameters are with their name=value pairings.
JSON or XML can reflect more closely the hierarchy in the underlying Lucene query objects. For me using a "flat" query interface feels a bit like when you start off trying to manage your application config in ".properties" files and quickly hit the limitations of their expressiveness. It's fine for simple things but complexity soon overwhelms. As well as hierarchical syntax it's worth considering the role a formal query schema has to play. The XMLQueryParser has a set of DTDs that currently serve to generate HTML documentation but also could conceivably be used by tooling to drive query construction. "Runnable documentation" always feels like a useful combo. Cheers Mark On 17 Nov 2011, at 20:21, Yonik Seeley wrote: > On Thu, Nov 17, 2011 at 3:18 PM, Uwe Schindler <u...@thetaphi.de> wrote: >> Sorry, this query is really ununderstandable. Those complex queries should >> have a meaningful language, e.g. a JSON object structure > > There are upsides and downsides to that. A big JSON object graph > would be easier to *read* but certainly not easier to write (much more > nesting). > These main Solr APIs are based around HTTP parameters... the upside > being you can add another parameter w/o worrying about nesting it > correctly. > > Like simply adding another filter for example: > fq=instock:true > > -Yonik > http://www.lucidimagination.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
