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 get a
: I confirmed this behavior in trunk with the following query:
: http://localhost:8983/solr/select?qt=dismaxq=6'2debugQuery=onqf=catpf=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 a
-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 avoids that.
We have auto-complete on titles, so the there are plenty
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!
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
I can get that string indexed, but I can't get it through the query
parser and into DisMax
: 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,
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 Hostetter
Some people loathe UTF-8 and do all of their text in XML entities. This
might work better for your punctuation needs. But it still won't help you
with Prince :)
-Original Message-
From: Walter Underwood [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 07, 2008 9:25 AM
To:
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%22version=2.2start=0rows=10indent=on
Input was:
item_name:Romeo+Juliet+category:books
Another input which works just fine: item_name:6'\ (user
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
: 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
Try this query with asterisk *
http://192.168.1.5:18080/apache-solr-1.2.0/select/?q=*version=2.2start=0r
ows=10indent=on
Response:
HTTP Status 400 - Query parsing error: Cannot parse '*': '*' or '?' not
allowed as first character in WildcardQuery
(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=onversion=2.2q=Ro
: http://192.168.1.5:18080/apache-solr-1.2.0/select/?q=*version=2.2start=0r
: ows=10indent=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 have
: 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
: Thursday, February 07, 2008 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 avoids
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... it
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 issues.
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
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: ... ... - ... ( ... * ...
... ... ... ... [ ... { ... ...
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 500.
21 matches
Mail list logo
