The fix to throw an exception if the user incorrectly attempts to perform a
phrase query on a field that does not have position info was made as part of
LUCENE-2370 - Reintegrate flex branch into trunk. Unfortunately, there is no
discussion there of that specific change, which was bundled as part of
"flex".
See:
https://issues.apache.org/jira/browse/LUCENE-2370
Maybe Uwe could comment on his change.
I suppose you could say that it was a "feature" that the error was
previously "silently ignored", but that would be a matter of debate. The
simple fact is that you are asking a module to do something that it cannot
do for the supplied index data.
You might want to propose that the query parsers avoid the exception,
possibly as an option, if a phrase if attempted against a non-position
field, which can happen easily when fields are listed in "qf", "pf", et al.
Years ago when I stumbled into this change I simply generated a boolean
query for the phrase if the field did not have position info.
There does appear to be an open Solr issue that may cover this: SOLR-2660 -
omitPositions improvements
See:
https://issues.apache.org/jira/browse/SOLR-2660
Maybe that's one difference between Lucene and Solr - Lucene is a precision
library for experts, while Solr is attempting to provide a search box for
casual users where getting some results I better even if the price is less
precision - or at least provide options to choose degrees of precision.
-- Jack Krupansky
-----Original Message-----
From: Rodland Fredrik
Sent: Tuesday, March 05, 2013 2:53 AM
To: solr-user@lucene.apache.org
Subject: Re: Trouble with phrase-queries on fields with
omitTermFreqAndPositions (upgrading from 3.6.X to 4.1)
-----Original Message----- From: Fredrik Rødland
Sent: Monday, March 04, 2013 6:14 AM
We've been trying to get our heads around this for some days now upgrading
from 3.6 (where we didn't see this error) to 4.1 (where this error is very
prominent.
We have upgraded from SOLR 3.6.1 to 4.1 and get the following error:
ERROR [2013.03.04 09:22:40] http-12200-2
org.apache.solr.servlet.SolrDispatchFilter -
null:java.lang.IllegalStateException: field "name" was indexed without
position data; cannot run PhraseQuery (term=a)
<name> is a field which has omitTermFreqAndPositions="true" for several
reasons.
We ran into several issues:
1. <name> was defined in our PF in our request handler (edismax)
=> resolution: delete it from PF
2. <name> has WordDelimiterFilter, and fails because WDF creates a phrase
behind the scenes.
=> resolution: update schema to >= 1.4 and add
autoGeneratePhraseQueries="true" to all other fields or types but <name>
(phuu)
3. excplicit phrase-queries fail. e.g a search for "audi oslo" fails with
the error above.
=> no resolution - other than stop using omitTermFreqAndPositions
from
http://wiki.apache.org/solr/SchemaXml#Schema_version_attribute_in_the_root_node
omitTermFreqAndPositions=true|false <!> Solr1.4
"...Queries that rely on position that are issued on a field with this
option will silently fail to find documents."
This doesn't seem very silent to me. We get a 500 error from SOLR.
Does anyone out there have any resolutions or tips for this problem. We
really wish to still have the field defined with omitTermFreqAndPositions,
have it defined in our qf and support phrases for the end user.
On a side note: Jan Høydals excellent auto-complete solution also suffers
from this - phrases are no longer supported, as noted in:
http://stackoverflow.com/questions/10063318/solr-autocomplete-based-on-edismax-type-error
4. mars 2013 kl. 22:29 skrev Jack Krupansky <j...@basetechnology.com>:
Sorry, but phrase queries really are dependent on position information, by
definition. So, if you want phrase query, don't omit position info.
Thanks for replying Jack.
I’m aware that you cannot run phrase queries against a field without
positions. I think that is quite clear in my post. And I don’t really
mind - as long as it doesn’t give a 500 error.
My point is that this used to (v3.6.X) work as excepted: if you don’t have
any position-info you won’t get any phrase-hits. To get a hit other fields
in your qf has to include the phrase. This is exactly the behavior we
really want going forward as well.
I’ve really dug to find any discussions on why this change has been made,
but haven’t found any, and wonder if it is unintentional. So my question is
really if someone has any pointers to a JIRA-ISSUE, somewhere else this
change is discussed, or any workarounds _other_ than the one already
mentioned in the post (include omitTermFreqAndPositions in all qf-fields if
you want to support end-user-phrases).
Regards,
Fredrik
--
Fredrik Rødland Cell: +47 99 21 98 17
Maisen Pedersens vei 1 Twitter: @fredrikr
NO-1363 Høvik, NORWAY flickr: http://www.flickr.com/fmmr/
http://rodland.no about.me http://about.me/fmr
