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).
> >
>
