All right let me put this. http://192.168.1.78:8983/solr/collection1/select?q=inStock:false&facet=true&facet.field=popularity&wt=xml&indent=true .
I just want to know what is this form. is it lucene query or this query should go under query parser to get converted to lucene query. Thanks, Vivek On Fri, Jun 20, 2014 at 5:19 PM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > That's *:* and a special case. There is no scoring here, nor searching. > Just a dump of documents. Not even filtering or faceting. I sure hope you > have more interesting examples. > > Regards, > Alex > On 20/06/2014 6:40 pm, "Vivekanand Ittigi" <vi...@biginfolabs.com> wrote: > > > Hi Daniel, > > > > You said inputs are "human-generated" and outputs are "lucene objects". > So > > my question is what does the below query mean. Does this fall under > > human-generated one or lucene.? > > > > http://localhost:8983/solr/collection1/select?q=*%3A*&wt=xml&indent=true > > > > Thanks, > > Vivek > > > > > > > > On Fri, Jun 20, 2014 at 3:55 PM, Daniel Collins <danwcoll...@gmail.com> > > wrote: > > > > > Alexandre's response is very thorough, so I'm really simplifying > things, > > I > > > confess but here's my "query parsers for dummies". :) > > > > > > In terms of inputs/outputs, a QueryParser takes a string (generally > > assumed > > > to be "human generated" i.e. something a user might type in, so maybe a > > > sentence, a set of words, the format can vary) and outputs a Lucene > Query > > > object ( > > > > > > > > > http://lucene.apache.org/core/4_8_1/core/org/apache/lucene/search/Query.html > > > ), > > > which in fact is a kind of "tree" (again, I'm simplifying I know) > since a > > > query can contain nested expressions. > > > > > > So very loosely its a translator from a human-generated query into the > > > structure that Lucene can handle. There are several different query > > > parsers since they all use different input syntax, and ways of handling > > > different constructs (to handle A and B, should the user type "+A +B" > or > > "A > > > and B" or just "A B" for example), and have different levels of support > > for > > > the various Query structures that Lucene can handle: SpanQuery, > > FuzzyQuery, > > > PhraseQuery, etc. > > > > > > We for example use an XML-based query parser. Why (you might well > ask!), > > > well we had an already used and supported query syntax of our own, > which > > > our users understood, so we couldn't use an off the shelf query parser. > > We > > > could have built our own in Java, but for a variety of reasons we parse > > our > > > queries in a front-end system ahead of Solr (which is C++-based), so we > > > needed an interim format to pass queries to Solr that was as near to a > > > Lucene Query object as we could get (and there was an existing XML > parser > > > to save us starting from square one!). > > > > > > As part of that Query construction (but independent of which > QueryParser > > > you use), Solr will also make use of a set of Tokenizers and Filters ( > > > > > > > > > https://cwiki.apache.org/confluence/display/solr/Understanding+Analyzers,+Tokenizers,+and+Filters > > > ) > > > but that's more to do with dealing with the terms in the query (so in > my > > > examples above, is A a real word, does it need stemming, lowercasing, > > > removing because its a stopword, etc). > > > > > >
