field "title_ngram" was indexed without position data; cannot run PhraseQuery
Hello, Could someone explain (or perhaps provide a documentation link) what does the following error mean: "field "title_ngram" was indexed without position data; cannot run PhraseQuery" I'll do some more searching online, I was just wondering if anyone has encountered this error before, and what the possible solution might be. I've recently upgraded my version of solr from 3.6.0 to 4.5.0, I'm not sure if this has any bearing or not. Thanks, M
Re: field "title_ngram" was indexed without position data; cannot run PhraseQuery
Hello, Thank you all for your help. There was indeed a property which was not set right in schema.xml: omitTermFreqAndPositions="true" After changing it to false phrase lookup started working OK. Thanks, M On 10/15/13 12:01 PM, Jack Krupansky wrote: Show us the field and field type from your schema. Likely you are "omitting" position info for the field, and the field type has "autoGeneratePhraseQueries="true"" - the ngram analyzer generates a sequence of terms for a single source term and then the query parser generates a PhraseQuery for that sequence, but that requires position info in the index but you have omitted them. That's one theory. So, if that theory is correct, either retain position info by getting rid of the "omit", or remove the autoGeneratePhraseQueries. -- Jack Krupansky -Original Message- From: Jason Hellman Sent: Tuesday, October 15, 2013 11:19 AM To: solr-user@lucene.apache.org Subject: Re: field "title_ngram" was indexed without position data; cannot run PhraseQuery If you consider what n-grams do this should make sense to you. Consider the following piece of data: White iPod If the field is fed through a bigram filter (n-gram with size of 2) the resulting token stream would appear as such: wh hi it te ip po od The usual use of n-grams is to match those partial tokens, essentially giving you a great deal of power in creating non-wildcard partial matches. How you use this is up to your imagination, but one easy use is in partial matches in autosuggest features. I can't speak for the intent behind the way it's coded, but it makes a great deal of sense to me that positional data would be seen as unnecessary since the intent of n-grams typically doesn't collide with phrase searches. If you need both behaviors it's far better to use copyField and have one field dedicated to standard tokenization and token filters, and another field for n-grams. I hope that's useful to you. On Oct 15, 2013, at 6:14 AM, MC wrote: Hello, Could someone explain (or perhaps provide a documentation link) what does the following error mean: "field "title_ngram" was indexed without position data; cannot run PhraseQuery" I'll do some more searching online, I was just wondering if anyone has encountered this error before, and what the possible solution might be. I've recently upgraded my version of solr from 3.6.0 to 4.5.0, I'm not sure if this has any bearing or not. Thanks, M
faceted search field sorting
Hello, Here is a public API that uses facet fields: http://golr.berkeleybop.org/select?qt=standard&fl=*&version=2.2&wt=json&indent=on&rows=0&facet=true&facet.field=type&q=document_category:%22annotation%22 It looks like the default behavior is to sort facet_counts.facet_fields (field called 'type' in this case) descending by frequency count among returned documents. I'd like to find out if this is a default behavior or if this is an extra step that Solr is performing and can be somehow turned off? I'd like to use that data to form a tag cloud and I'd like to avoid the random shuffle step if that is something that can be turned off in Solr query. If this is the default result maybe someone could explain how faceted index works on Solr side, and where does that order come from? I'd like to understand it better either way. Thanks, M
which jar contains org.apache.solr.request.XSLTResponseWriter ?
Hello, My embedded solr server (4.4.0) is crashing when I submit a query. The reason is this: Caused by: java.lang.ClassNotFoundException: org.apache.solr.request.XSLTResponseWriter I have the following jars in my classpath: solr-core-4.4.0.jar solr-solrj-4.4.0.jar solr-dataimporthandler-4.4.0.jar solr-dataimporthandler-extras-4.4.0.jar I checked contents of the solr-core jar, there is a file called XSLTResponseWriter in it, but it's in org.apache.solr.response package, not in org.apache.solr.request package. I'm guessing there should be another jar? Thanks, M
Re: which jar contains org.apache.solr.request.XSLTResponseWriter ?
Shawn thank you for your help. I had another look at my settings, and although classpath and code were OK, I found this entry in solrconfig.xml: class="org.apache.solr.request.XSLTResponseWriter"> That was the problem. So you were right, it was a relic of the old version. My code started working after I changed it to this: class="org.apache.solr.response.XSLTResponseWriter"> Thanks a lot, M On 10/10/13 1:50 PM, Shawn Heisey wrote: On 10/10/2013 10:15 AM, MC wrote: My embedded solr server (4.4.0) is crashing when I submit a query. The reason is this: Caused by: java.lang.ClassNotFoundException: org.apache.solr.request.XSLTResponseWriter I have the following jars in my classpath: solr-core-4.4.0.jar solr-solrj-4.4.0.jar solr-dataimporthandler-4.4.0.jar solr-dataimporthandler-extras-4.4.0.jar I checked contents of the solr-core jar, there is a file called XSLTResponseWriter in it, but it's in org.apache.solr.response package, not in org.apache.solr.request package. In Solr 3.x, that class is in the org.apache.solr.request package. Looks like it got moved in 4.x. This seems to indicate one of two things are in your classpath: 1) Solr or SolrJ 3.x jars 2) Something else designed for use (and compiled) with Solr/SolrJ version 3.x. I'm guessing that the source of the problem is your application . Chances are that it was written and compiled against Solr/SolrJ 3.x, but you're trying to use it with version 4.4.0 without modifying or recompiling it. That kind of major version jump just isn't possible. A minor version jump is likely to work, but I wouldn't even be too sure about that. If this is what's happening, the application source code will need to be updated for the new version and it will need to be recompiled against the 4.4.0 jars. Thanks, Shawn
