> With DisMax, and simple query which is single double-quote
> character, SOLR
> responds with
> 500
> org.apache.solr.common.SolrException: Cannot parse '':
...
> It is not polite neither to user's input nor to HTTP specs...
Ooohh... Sorry again: it is the only case where SOLR is polite with
With DisMax, and simple query which is single double-quote character, SOLR
responds with
500
org.apache.solr.common.SolrException: Cannot parse '': Encountered "" at
line 1, column 0. Was expecting one of: ... " " ... "-" ... "(" ... "*" ...
... ... ... ... "[" ... "{" ... ...
org.apache.lucene.q
On Feb 7, 2008 8:35 PM, Fuad Efendi <[EMAIL PROTECTED]> wrote:
> - is it a bug of DixMax?... It happens even before request reaches dismax.
That's what this whole thread has been about :-)
Stripping unbalanced quotes is part of dismax.
-Yonik
> > I think: no. And 6'2" works just as prescribed:
>
> Not really... it depends on the analyzer. If the index analyzer for
> the field ends up stripping off the trailing quote anyway, then the
> dismax query (which also dropped the quote) will match documents.
> That's why you don't see any issu
On Feb 7, 2008 6:35 PM, Fuad Efendi <[EMAIL PROTECTED]> wrote:
> Anyway I can't understand where is the problem?!! Everything works fine with
> dismax/standard/escaping/encoding.
> Can we use AND operator with dismax by
> the way?
No.
> I think: no. And 6'2" works just as prescribed:
Not really
> (catalina.out file of SOLR,
> http://www.tokenizer.org/armani/price.htm?q=Romeo%2bJuliet
> from production)
> ...
> ... DISMAX queries via CONSOLE do not support
> that...
Opsss... Again mistake, sorry.
http://192.168.1.5:18080/apache-solr-1.2.0/select?indent=on&version=2.2&q=Ro
meo%2BJuliet&s
> while i agree that you don't wnat to expose your end users
> directly to
> Solr (largely for security reasons) that doesn't mean you *must*
> preprocess user entered strings before handing them to dismax
> ... dismax's
> whole goal is to make it posisble for apps to not have to worry about
: It is not a bug/problem of SOLR. SOLR can't be exposed directly to end
: users. For handling user input and generating SOLR-specific query, use
while i agree that you don't wnat to expose your end users directly to
Solr (largely for security reasons) that doesn't mean you *must*
preprocess us
: http://192.168.1.5:18080/apache-solr-1.2.0/select/?q=*&version=2.2&start=0&r
: ows=10&indent=on
That's using standard request handler right? ... that's a much differnet
discussion -- when using standard you must of course be aware of hte
syntax and the special characters ... Walter and i hav
This is what appears in Address Bar of IE:
http://localhost:8080/apache-solr-1.2.0/select/?q=item_name%3A%22Romeo%2BJul
iet%22%2Bcategory%3A%22books%22&version=2.2&start=0&rows=10&indent=on
Input was:
item_name:"Romeo+Juliet"+category:"books"
Another input which works just fine: item_name:"6'\""
Try this query with asterisk *
http://192.168.1.5:18080/apache-solr-1.2.0/select/?q=*&version=2.2&start=0&r
ows=10&indent=on
Response:
HTTP Status 400 - Query parsing error: Cannot parse '*': '*' or '?' not
allowed as first character in WildcardQuery
: Our users can blow up the parser without special characters.
:
: AND THE BAND PLAYED ON
: TO HAVE AND HAVE NOT
Grrr... yeah, i'd forgotten about that problem. I was hopping LUCENE-682
could solve that (by "unregistering" AND/OR/NOT as operators) but that
issue fairly dead in the water si
gt; Subject: RE: Query with literal quote character: 6'2"
>
>
> This query works just fine:
> http://www.tokenizer.org/?q=Romeo+%2B+Juliet
>
> %2B is URL-Encoded presentation of +
> It shows, for instance, [Romeo & Juliet] in output.
>
>
> > -O
3:25 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Query with literal quote character: 6'2"
>
>
> Our users can blow up the parser without special characters.
>
> AND THE BAND PLAYED ON
> TO HAVE AND HAVE NOT
>
> Lower-casing in the front end avoi
Our users can blow up the parser without special characters.
AND THE BAND PLAYED ON
TO HAVE AND HAVE NOT
Lower-casing in the front end avoids that.
We have auto-complete on titles, so the there are plenty
of chances to inadvertently use special characters:
Romeo + Juliet
Airplane!
Sh
ry 07, 2008 12:58 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Query with literal quote character: 6'2"
>
>
> On Feb 7, 2008 12:24 PM, Walter Underwood
> <[EMAIL PROTECTED]> wrote:
> > We have a movie with this title: 6'2"
> >
: How about the query parser respecting backslash escaping? I need
one of the orriginal design decisions was "no user escaping" ... be able
to take in raw query strings from the user with only '+' '-' and '"'
treated as special characters ... if you allow backslash escaping of those
characters
Sent: Thursday, February 07, 2008 9:25 AM
> To: solr-user@lucene.apache.org
> Subject: Query with literal quote character: 6'2"
>
> We have a movie with this title: 6'2"
>
> I can get that string indexed, but I can't get it through the query parser
&g
-user@lucene.apache.org
Subject: Query with literal quote character: 6'2"
We have a movie with this title: 6'2"
I can get that string indexed, but I can't get it through the query parser
and into DisMax. It goes through the analyzers fine. I can run the analysis
tool in the a
How about the query parser respecting backslash escaping? I need
free-text input, no syntax at all. Right now, I'm escaping every
Lucene special character in the front end. I just figured out that
it breaks for colon, can't search for "12:01" with "12\:01".
wunder
On 2/7/08 11:06 AM, "Chris Hoste
: I confirmed this behavior in trunk with the following query:
: http://localhost:8983/solr/select?qt=dismax&q=6'2"&debugQuery=on&qf=cat&pf=cat
:
: The result is that the double quote is dropped:
: +DisjunctionMaxQuery((cat:6'2)~0.01) DisjunctionMaxQuery((cat:6'2)~0.01)
:
: This seems like it's
On Feb 7, 2008 12:24 PM, Walter Underwood <[EMAIL PROTECTED]> wrote:
> We have a movie with this title: 6'2"
>
> I can get that string indexed, but I can't get it through the query
> parser and into DisMax. It goes through the analyzers fine. I can
> run the analysis tool in the admin interface and
We have a movie with this title: 6'2"
I can get that string indexed, but I can't get it through the query
parser and into DisMax. It goes through the analyzers fine. I can
run the analysis tool in the admin interface and get a match with
that exact string.
These variants don't work:
6'2"
6'2\"
6
23 matches
Mail list logo
