Re: query parsing output in analysis page and query page are different

rsing and... it's kind of confusing. Try escaping the asterisk as it has special meaning for the query parsing. Best, Erick On Mon, Aug 7, 2017 at 6:38 PM, radha krishnan wrote: > Hi, > > I created the following fieldType in schema.xml > > positionIncrementGap="100"&g

query parsing output in analysis page and query page are different

Hi, I created the following fieldType in schema.xml mapping.txt contains the following (replacing dot with white space) "." => " " and using the above in the field 1. in the analysis page on the solr UI (http://localhost:8984/solr/#/tenant1-core-1/analysis)

RE: How to avoid unnecessary query parsing on distributed search in QueryComponent.prepare()?

tring to a real object, could that be lighter than parsing the incoming query text? Markus -Original message- > From:Mikhail Khludnev > Sent: Thursday 11th May 2017 10:43 > To: solr-user > Subject: How to avoid unnecessary query parsing on distributed search in &g

How to avoid unnecessary query parsing on distributed search in QueryComponent.prepare()?

Hello, When the distributed search is requested (SolrCloud), the query component invokes prepare() where a query is parsed. But then it's just ignored, I suppose because all work is done by subordinate shards' requests. It's fine the most of the times because query parsing is cheap

Pointless query parsing before distributed processing

Hello, Before distributed requests are submitted, QueryComponent.prepare() is invoked and parses the query, but then that parsed query is just thrown away (probably it appears in debug). It's neglectable for the most of the cases until a heavy wildcarded {!complexphrase} query is submitted. It can

Re: Edismax query parsing in Solr 4 vs Solr 6

eason to want it. If it was set to '100%' it > might insert the additional '+' flags, but it can also show up as a '~' > operator on the end. > > Ta, > Greg > > On 8 November 2016 at 22:13, Max Bridgewater > wrote: > > > I am migrating a so

Re: Edismax query parsing in Solr 4 vs Solr 6

hich I suspect should be set to '0' unless you have some reason to want it. If it was set to '100%' it might insert the additional '+' flags, but it can also show up as a '~' operator on the end. Ta, Greg On 8 November 2016 at 22:13, Max Bridgewater wrote

Edismax query parsing in Solr 4 vs Solr 6

I am migrating a solr based app from Solr 4 to Solr 6. One of the discrepancies I am noticing is around edismax query parsing. My code makes the following call: userQuery="+(title:shirts isbn:shirts) +(id:20446 id:82876)" Query query=QParser.getParser(userQuery, "edismax&

Re: changed query parsing between 4.10.4 and 5.5.3?

r internals > >>>>> and don't give any notice about how to keep old parsing behavior. > >>>>> > >>>>> From my point of view the old parsing behavior was correct. > >>>>> If searching for a term without operator it is always

Re: changed query parsing between 4.10.4 and 5.5.3?

>>> I forgot to mention the tickets: > >>> SOLR-2649 and SOLR-8812 > >>> > >>> On 9 September 2016 at 13:38, Greg Pendlebury < > greg.pendleb...@gmail.com > >>> > >>> wrote: > >>> > >>>> Under 4.10

Re: changed query parsing between 4.10.4 and 5.5.3?

>>>>> Regards >>>>> Bernd >>>>> >>>>> Am 09.09.2016 um 05:43 schrieb Greg Pendlebury: >>>>>> I forgot to mention the tickets: >>>>>> SOLR-2649 and SOLR-8812 >>>>>> >>>>>&g

Re: changed query parsing between 4.10.4 and 5.5.3?

On Sun, Sep 11, 2016 at 11:29 PM, Greg Pendlebury wrote: > I'm not certain what is going on with your boost. It doesn't seem related > to those tickets as far as I can see, but I note it comes back in the > 'parsedquery_toString' step below that. Perhaps the debug output has a > display bug? Yeah

Re: changed query parsing between 4.10.4 and 5.5.3?

parsing and searching? > >>> > >>> Regards > >>> Bernd > >>> > >>> Am 09.09.2016 um 05:43 schrieb Greg Pendlebury: > >>>> I forgot to mention the tickets: > >>>> SOLR-2649 and SOLR-8812 > >>>> > >>>> On

Re: changed query parsing between 4.10.4 and 5.5.3?

, parsing and searching? >>> >>> Regards >>> Bernd >>> >>> Am 09.09.2016 um 05:43 schrieb Greg Pendlebury: >>>> I forgot to mention the tickets: >>>> SOLR-2649 and SOLR-8812 >>>> >>>> On 9 September 2016 at 13:38, Gr

Re: changed query parsing between 4.10.4 and 5.5.3?

ted. >>>> >>>> There are also some changes to the default values selected for mm, but I >>>> doubt those apply here since you are setting it explicitly. >>>> >>>> On 8 September 2016 at 00:35, Mikhail Khludnev wrote: >>>>

Re: changed query parsing between 4.10.4 and 5.5.3?

ion the tickets: > >> SOLR-2649 and SOLR-8812 > >> > >> On 9 September 2016 at 13:38, Greg Pendlebury < > greg.pendleb...@gmail.com> > >> wrote: > >> > >>> Under 4.10 q.op was ignored by the edismax parser and always forced to > OR. &g

Re: changed query parsing between 4.10.4 and 5.5.3?

tly. > >> > >> On 8 September 2016 at 00:35, Mikhail Khludnev wrote: > >> > >>> I suppose > >>>+((text:star text:trek)~2) > >>> and > >>> +(+text:star +text:trek) > >>> are equal. mm=2 is equal to +fo

Re: changed query parsing between 4.10.4 and 5.5.3?

;> >>> On 8 September 2016 at 00:35, Mikhail Khludnev wrote: >>> >>>> I suppose >>>>+((text:star text:trek)~2) >>>> and >>>> +(+text:star +text:trek) >>>> are equal. mm=2 is equal to +foo +bar >>

Re: changed query parsing between 4.10.4 and 5.5.3?

xt:trek)~2) >>> and >>> +(+text:star +text:trek) >>> are equal. mm=2 is equal to +foo +bar >>> >>> On Wed, Sep 7, 2016 at 10:52 AM, Bernd Fehling < >>> bernd.fehl...@uni-bielefeld.de> wrote: >>> >>>> Hi list, &g

Re: changed query parsing between 4.10.4 and 5.5.3?

equal to +foo +bar >> >> On Wed, Sep 7, 2016 at 10:52 AM, Bernd Fehling < >> bernd.fehl...@uni-bielefeld.de> wrote: >> >> > Hi list, >> > >> > while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query >> parsing. >> &g

Re: changed query parsing between 4.10.4 and 5.5.3?

; while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query > parsing. > > 4.10.4 > > text:star text:trek > > text:star text:trek > > (+((text:star text:trek)~2))/no_coord > > +((text:star text:trek)~2) > > > > 5.5.3 > > text:star text:

Re: changed query parsing between 4.10.4 and 5.5.3?

I suppose +((text:star text:trek)~2) and +(+text:star +text:trek) are equal. mm=2 is equal to +foo +bar On Wed, Sep 7, 2016 at 10:52 AM, Bernd Fehling < bernd.fehl...@uni-bielefeld.de> wrote: > Hi list, > > while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query pa

Re: changed query parsing between 4.10.4 and 5.5.3?

> The tilde in the former looks interesting. > I think it related to proximity search. > What query parser is this? > > Ahmet > > > > On Wednesday, September 7, 2016 10:52 AM, Bernd Fehling > wrote: > Hi list, > > while going from SOLR 4.10.4 to 5.5.3

Re: changed query parsing between 4.10.4 and 5.5.3?

Hi, The tilde in the former looks interesting. I think it related to proximity search. What query parser is this? Ahmet On Wednesday, September 7, 2016 10:52 AM, Bernd Fehling wrote: Hi list, while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query parsing. 4.10.4 text:star

changed query parsing between 4.10.4 and 5.5.3?

Hi list, while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query parsing. 4.10.4 text:star text:trek text:star text:trek (+((text:star text:trek)~2))/no_coord +((text:star text:trek)~2) 5.5.3 text:star text:trek text:star text:trek (+(+text:star +text:trek))/no_coord

Re: Difference in boolean query parsing. Solr-5.4.0 VS Solr.6.1.0

It’s fairly likely these differences are as a result of SOLR-2649[1] (released with 5.5) and SOLR-8812[2] (released with 6.1). If you haven’t seen it, I recommend you read Hoss'ss blog “Why Not AND, OR, And NOT?” . If you can, add

Difference in boolean query parsing. Solr-5.4.0 VS Solr.6.1.0

Hi, During migration from Solr-5.4.1 to Solr-6.1.0 I saw a difference in the behavior of few of my boolean queries. As per my current understanding the default operator comes in when there is no operator present in between two terms. Also both the ANDed terms are marked mandatory if not, any of th

Re: Function Query Parsing problem in Solr 5.4.1 and Solr 5.5.0

Thank you Mike, that was it. Max. On Sat, Apr 2, 2016 at 2:40 AM, Mikhail Khludnev wrote: > Hello Max, > > Since it reports the first space occurrence pos=32, I advise to nuke all > spaces between braces in sum(). > > On Fri, Apr 1, 2016 at 7:40 PM, Max Bridgewater > > wrote: > > > Hi, > > >

Re: Function Query Parsing problem in Solr 5.4.1 and Solr 5.5.0

Hello Max, Since it reports the first space occurrence pos=32, I advise to nuke all spaces between braces in sum(). On Fri, Apr 1, 2016 at 7:40 PM, Max Bridgewater wrote: > Hi, > > I have the following configuration for firstSearcher handler in > solrconfig.xml: > > > > > >

Function Query Parsing problem in Solr 5.4.1 and Solr 5.5.0

Hi, I have the following configuration for firstSearcher handler in solrconfig.xml: parts score desc, Review1 asc, Rank2 asc make {!func}sum(product(0.01,param1), product(0.20,param2), min(param2,0.4)) desc

Re: query parsing

> guessing wrong (again and again and again). This is the classic weakness >>>> of >>>> schemaless. It's great for indexing stuff fast, but if it guesses wrong >>>> you're stuck. >>>> >>>> >>>> So to the origi

Re: query parsing

schema.xml file semi-redundant? Regards, Geraint Geraint Duck Data Scientist Toxicology and Health Sciences Syngenta UK Email: geraint.d...@syngenta.com -Original Message- From: Alessandro Benedetti [mailto:benedetti.ale...@gmail.com] Sent: 24 September 2015 09:23 To: solr-user@lucene

Re: query parsing

Thu, Sep 24, 2015 at 2:02 AM, Duck Geraint (ext) GBJH < >> geraint.d...@syngenta.com> wrote: >> >>> Okay, so maybe I'm missing something here (I'm still relatively new to >>> Solr myself), but am I right in thinking the following is still in your &g

Re: query parsing

the following is still in your solrconfig.xml file: true managed-schema If so, wouldn't using a managed schema make several of your field definitions inside the schema.xml file semi-redundant? Regards, Geraint Geraint Duck Data Scientist Toxicology and Health Sciences S

Re: query parsing

schema.xml file semi-redundant? > > Regards, > Geraint > > > Geraint Duck > Data Scientist > Toxicology and Health Sciences > Syngenta UK > Email: geraint.d...@syngenta.com > > > -Original Message- > From: Alessandro Benedetti [mailto:benedetti.ale...

RE: query parsing

3 To: solr-user@lucene.apache.org Subject: Re: query parsing I would focus on this : " > 5> now kick off the DIH job and look again. > Now it shows a histogram, but most of the "terms" are long -- the full texts of (the table.column) eventlogtext.logtext, including the whitespace

Re: query parsing

I would focus on this : " > 5> now kick off the DIH job and look again. > Now it shows a histogram, but most of the "terms" are long -- the full texts of (the table.column) eventlogtext.logtext, including the whitespace (with %0A used for newline characters)... So, it appears it is not being tok

Re: query parsing

typically, the index dir is inside the data dir. Delete the index dir and you should be good. If there is a tlog next to it, you might want to delete that also. If you dont have a data dir, i wonder whether you set the data dir when creating your core or collection. Typically the instance dir and

Re: query parsing

OK, this is bizarre. You'd have had to set up SolrCloud by specifying the -zkRun command when you start Solr or the -zkHost; highly unlikely. On the admin page there would be a "cloud" link on the left side, I really doubt one's there. You should have a data directory, it should be the parent of t

Re: query parsing

On 9/23/2015 12:30 PM, Erick Erickson wrote: Then my next guess is you're not pointing at the index you think you are when you 'rm -rf data' Just ignore the Elall field for now I should think, although get rid of it if you don't think you need it. DIH should be irrelevant here. So let's back u

Re: query parsing

Then my next guess is you're not pointing at the index you think you are when you 'rm -rf data' Just ignore the Elall field for now I should think, although get rid of it if you don't think you need it. DIH should be irrelevant here. So let's back up. 1> go ahead and "rm -fr data" (with Solr sto

Re: query parsing

On 9/23/2015 11:28 AM, Erick Erickson wrote: This is totally weird. Don't only re-index your old docs, find the data directory and rm -rf data (with Solr stopped) and re-index. I pretty much do that. The thing is: I don't have a data directory anywhere! Most of my stuff is in /localapps/dev/E

Re: query parsing

This is totally weird. Don't only re-index your old docs, find the data directory and rm -rf data (with Solr stopped) and re-index. re: the analysis page Alessandro mentioned. Go to the Solr admin UI (http://localhost:8983/solr). You'll see a drop-down on the left that lets you select a core, sel

Re: query parsing

On 9/23/2015 10:21 AM, Alessandro Benedetti wrote: m so those 2 are the queries at the minute : 1) logtext:deeper 2) logtext:*deeper* According to your schema, the log text field is of type "text_en". This should be completely fine. Have you ever changed your schema on run ? without re-inde

Re: query parsing

gov/ohrfc/Forecast.php\n$$\nFor > <http://weather.gov/ohrfc/Forecast.php%5Cn$$%5CnFor> critical after-hours > support, the OHRFC cell number is 937-725-.\nLink Crawford "], > "username":["crawford"], > "_version_":15129287678

Re: query parsing

;2012-07-10 13:23:39.0":"\n1.0 = logtext:*deeper*, product of:\n 1.0 = boost\n 1.0 = queryNorm\n", "2012-07-10 17:39:09.0":"\n1.0 = logtext:*deeper*, product of:\n 1.0 = boost\n 1.0 = queryNorm\n", "2012-07-11 12:39:56.0":"\n1.0 =

Re: query parsing

Hi Mark, Search is not coming properly becuase you have taken "ELall" field as a text type which is not define properly. you have to modify the schema.xml with these chance. -- View this message in context: http://lucene.472066.n3.nabble.com/que

Re: query parsing

If you go to the Analysis tool, indexing and query time , what can you see for your "deeper" query text and your field content ? ( using the log text field ) ? Have you verified the current tokens in the index for that field ? I quickly went through your config files, and they look ok, but it is q

query parsing

When I submit this: http://localhost:8983/solr/EventLog/select?q=deeper&wt=json&indent=true then I get these (empty) results: { "responseHeader":{ "status":0, "QTime":1, "params":{ "q":"deeper", "indent":"true", "wt":"json"}}, "response":{"numFound":0,"start":

Re: SpellingQueryConverter and query parsing

mailto:sstu...@opensourceconnections.com] > Sent: Tuesday, January 27, 2015 11:26 AM > To: solr-user@lucene.apache.org > Subject: SpellingQueryConverter and query parsing > > Hello! > > SpellingQueryConverter "parses" the incoming query in sort of a quick and > dirty way

RE: SpellingQueryConverter and query parsing

a final polished state for general use. James Dyer Ingram Content Group -Original Message- From: Scott Stults [mailto:sstu...@opensourceconnections.com] Sent: Tuesday, January 27, 2015 11:26 AM To: solr-user@lucene.apache.org Subject: SpellingQueryConverter and query parsing Hello! S

SpellingQueryConverter and query parsing

Hello! SpellingQueryConverter "parses" the incoming query in sort of a quick and dirty way with a regular expression. Is there a reason the query string isn't parsed with the _actual_ parser, if one was configured for that type of request? Even better, could the parsed query object be added to the

Re: Query parsing - difference between Analysis and parsedquery_toString output [SOLVED]

Thanks guys for a quick reply, Adding ( ) to query values resolved the issue! Tanya -- View this message in context: http://lucene.472066.n3.nabble.com/Query-parsing-difference-between-Analysis-and-parsedquery-toString-output-tp4164851p4164912.html Sent from the Solr - User mailing list

Re: Query parsing - difference between Analysis and parsedquery_toString output

le_t&defType=edismax -- View this message in context: http://lucene.472066.n3.nabble.com/Query-parsing-difference-between-Analysis-and-parsedquery-toString-output-tp4164851p4164884.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Query parsing - difference between Analysis and parsedquery_toString output

itle_t:The Hershey > Company^1000" > "parsedquery_toString": "manufacture_t:the text:Hershey text:Company^100.0 > title_t:the text:Hershey text:Company^1000.0", > > indexed document: >"docs": [ > { > "id": "0001

Query parsing - difference between Analysis and parsedquery_toString output

oppers Carton - 12 Pack" ], "manufacture_t": [ "Hershey's" ], What do I miss? Thanks in advance, Tanya -- View this message in context: http://lucene.472066.n3.nabble.com/Query-parsing-difference-between-Analysis-and-parsedquery-toString-output-tp4164851.html Sent from the Solr - User mailing list archive at Nabble.com.

R: Query parsing issue

dì 6 marzo 2013 19:39 A: solr-user@lucene.apache.org Oggetto: Re: Query parsing issue It should be easy to extend ExtendedDismaxQParser and do your pre-processing in the parse() method before calling edismax's parse. Or maybe you could change the way EDismax is splitting the input query into claus

Re: Query parsing issue

It should be easy to extend ExtendedDismaxQParser and do your pre-processing in the parse() method before calling edismax's parse. Or maybe you could change the way EDismax is splitting the input query into clauses by extending the "splitIntoClauses" method? Tomás On Wed, Mar 6, 2013 at 6:37 AM,

Query parsing issue

Hi, I’ve written my own analyzer to index and query a set of documents. At indexing time everything goes well but now I have a problem in query phase. I need to pass the whole query string to my analyzer before the edismax query parser begins its tasks. In other words I have to prepro

Re: Query parsing VS marshalling/unmarshalling

://lucene.472066.n3.nabble.com/Query-parsing-VS-marshalling-unmarshalling-tp3935430p4033985.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Query parsing VS marshalling/unmarshalling

nford-295-talk.pdf > , slide 13 > > m. > > On Tue, Apr 24, 2012 at 4:43 PM, Erick Erickson > wrote: >> In general, query parsing is such a small fraction of the total time that, >> almost no matter how complex, it's not worth worrying about. To see >> this,

Re: Query parsing VS marshalling/unmarshalling

h requests. [1] http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//people/jeff/stanford-295-talk.pdf , slide 13 m. On Tue, Apr 24, 2012 at 4:43 PM, Erick Erickson wrote: > In general, query parsing is such a small fraction of the total time that, >

Re: Query parsing VS marshalling/unmarshalling

In general, query parsing is such a small fraction of the total time that, almost no matter how complex, it's not worth worrying about. To see this, attach &debugQuery=on to your query and look at the timings in the "pepare" and "process" portions of the response. I&

Re: Query parsing VS marshalling/unmarshalling

alizable (haven't done a thorough check but looks good on the surface) - other conversions (e.g. using Xtream) are either slow or require custom annotations. I personally don't see how would Lucene/Solr include them in their core classes. Anyway, it would still be interesting to hear

Re: Query parsing VS marshalling/unmarshalling

2012/4/24 Mindaugas Žakšauskas : > Hi, > > I maintain a distributed system which Solr is part of. The data which > is kept is Solr is "permissioned" and permissions are currently > implemented by taking the original user query, adding certain bits to > it which would make it return less data in the

Query parsing VS marshalling/unmarshalling

Hi, I maintain a distributed system which Solr is part of. The data which is kept is Solr is "permissioned" and permissions are currently implemented by taking the original user query, adding certain bits to it which would make it return less data in the search results. Now I am at the point where

Re: sub query parsing bug???

Well, your query below becomes ref_expertise:(nonlinear OR soliton) AND default_search:"optical lattice:" The regular Solr/Lucene query should handle pretty much anything you can throw at it. But do be aware that Solr/Lucene syntax is not true boolean logic, you have to think in terms of SHOULD, M

Re: sub query parsing bug???

Thanks for the reply! I do believe I have set (or have tried setting) all of those options for the default query and none of them seem to help. Anytime an OR appears inside the query the default for that query becomes OR. At least thats the anecdotal evidence I've encountered. Also in this case

Re: sub query parsing bug???

Hmmm, does this help? In Solr 1.4 and prior, you should basically set mm=0 if you want the equivilent of q.op=OR, and mm=100% if you want the equivilent of q.op=AND. In 3.x and trunk the default value of mm is dictated by the q.op param (q.op=AND => mm=100%; q.op=OR => mm=0%). Keep in mind the def

sub query parsing bug???

Hello All, I have my field description listed below, but I don't think its pertinent. As my issue seems to be with the query parser. I'm currently using an edismax subquery clause to help with my searching as such: _query_:"{!type=edismax qf='ref_expertise'}\(nonlinear OR soliton\) AND \"opti

Re: question about query parsing

Am 09.08.2011 14:58, schrieb Ahmet Arslan: while searching with debug on I see strange query parsing: identifier:"ub.uni-bielefeld.de" identifier:"ub.uni-bielefeld.de" +MultiPhraseQuery(identifier:"(ub.uni-bielefeld.de ub) uni bielefeld de") +identifier

Re: question about query parsing

> while searching with debug on I see strange query parsing: > > name="rawquerystring">identifier:"ub.uni-bielefeld.de" > name="querystring">identifier:"ub.uni-bielefeld.de" > > +MultiPhraseQuery(identifier:"(ub.u

question about query parsing

Hi list, while searching with debug on I see strange query parsing: identifier:"ub.uni-bielefeld.de" identifier:"ub.uni-bielefeld.de" +MultiPhraseQuery(identifier:"(ub.uni-bielefeld.de ub) uni bielefeld de") +identifier:"(ub.uni-bielefeld.de ub) uni bielef

Re: query parsing - removes a term

Do you use stop word removal on text field? Dmitry On Tue, Jun 14, 2011 at 9:18 PM, Andrea Eakin < andrea.ea...@systemsbiology.org> wrote: > I am trying to do the following type of query: > > +text:(was wasp) +pub_date_year:[1991 TO 2011] > > When I turn debugQuery=on I find that the parsedquery

query parsing - removes a term

I am trying to do the following type of query: +text:(was wasp) +pub_date_year:[1991 TO 2011] When I turn debugQuery=on I find that the parsedquery is only sending in the +text:(wasp) on parsing, and doesn't use the "was" value. Why is it removing one of the terms? Thanks! Andrea

Re: Solr query parsing

: Why would fq=sdate:+20100110 parse via a Solr server but not via : QueryParsing.parseQuery? Its choking on the + symbol in the sdate : value. is it something as simple as the fact that with a Solr Server the "+" is a URL escaped " " ? hard to say w/o knowing qhatr exactly it is you are doing

Solr query parsing

Why would fq=sdate:+20100110 parse via a Solr server but not via QueryParsing.parseQuery? Its choking on the + symbol in the sdate value. I'd use QParserPlugin however it requires passing a SolrQueryRequest, which is not kosher for testing, perhaps I'll need to bite the bullet and reproduce using

Re: filter query parsing problem

mon that fq's are used to drill into facets, which are themselves most often indexed as "string" type. So, an fq=category:"Music and Electronics" is not really "analyzed" per se. But, in general that is a Lucene query expression. I actually really strongly recom

Re: filter query parsing problem

On Wed, Jan 20, 2010 at 7:40 PM, Erik Hatcher wrote: > > On Jan 20, 2010, at 8:11 AM, Ahmet Arslan wrote: > > If they are really filter queries i.e. specified through >>> "fq" then they will >>> not be run through an analyzer. >>> >>> >> Does this mean filter queries are not analyzed? The query b

Re: filter query parsing problem

On Jan 20, 2010, at 8:11 AM, Ahmet Arslan wrote: If they are really filter queries i.e. specified through "fq" then they will not be run through an analyzer. Does this mean filter queries are not analyzed? The query below returns a document. http://localhost:8983/solr/select/?q=*%3A*&ver

Re: filter query parsing problem

> If they are really filter queries i.e. specified through > "fq" then they will > not be run through an analyzer. > Does this mean filter queries are not analyzed? The query below returns a document. http://localhost:8983/solr/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on&debugQuery=on

Re: filter query parsing problem

On Tue, Jan 19, 2010 at 3:10 AM, Ahmet Arslan wrote: > > I am submitting a query and it seems > > to be parsing incorrectly. Here > > is the query with the debug output. Any ideas what > > the problem is: > > > > > > > > ((VLog:814124 || VLog:12342) && > > (PublisherType:U || PublisherT

Re: filter query parsing problem

Ahmet, Thanks so much for the help. I will give it a shot. John On Mon, Jan 18, 2010 at 4:40 PM, Ahmet Arslan wrote: >> I am submitting a query and it seems >> to be parsing incorrectly.  Here >> is the query with the debug output.  Any ideas what >> the problem is: >> >> >>   >>     ((VLog:

Re: filter query parsing problem

> I am submitting a query and it seems > to be parsing incorrectly.  Here > is the query with the debug output.  Any ideas what > the problem is: > > >   >     ((VLog:814124 || VLog:12342) && > (PublisherType:U || PublisherType:A)) >   > > >     +(VLog:814124 VLog:12342) > +PublisherType:u >

filter query parsing problem

I am submitting a query and it seems to be parsing incorrectly. Here is the query with the debug output. Any ideas what the problem is: ((VLog:814124 || VLog:12342) && (PublisherType:U || PublisherType:A)) +(VLog:814124 VLog:12342) +PublisherType:u I would have thought that th

Re: query parsing ( expansion ) in solr

Hello, Thanks. This would absolutely serve. I thought of doing it in queryparser part which I mentioned in first mail. But if the query is a complex one, then it would become a bit complicated. Thats why I wanted to know whether there is any other way which is similar to the second point

Re: query parsing ( expansion ) in solr

> Hi, >      I have explored > "DisMaxRequestHandler". It could serve for some > of my purposes but not all. > 1) It seems we have to decide that alternative field list > beforehand > and declare them in the config.xml . But the field list for > which > synonyms are to be considered is not definite

Re: query parsing ( expansion ) in solr

Hi, I have explored "DisMaxRequestHandler". It could serve for some of my purposes but not all. 1) It seems we have to decide that alternative field list beforehand and declare them in the config.xml . But the field list for which synonyms are to be considered is not definite ( at least in the

Re: query parsing ( expansion ) in solr

> Hello All, >             I have been > trying to find out the right place to parse > the query submitted. To be brief, I need to expand the > query. For > example.. let the query be >        city:paris > then I would like to expand the query as .. follows >     city:paris OR place:paris OR town:

query parsing ( expansion ) in solr

Hello All, I have been trying to find out the right place to parse the query submitted. To be brief, I need to expand the query. For example.. let the query be city:paris then I would like to expand the query as .. follows city:paris OR place:paris OR town:paris . I gue

Re: Overview of Query Parsing API Stack? / Dismax parsing, new 1.4 parsing, etc.

also thought it would be more "granular". Have you chatted with them to confirm? -- Mark Bennett / New Idea Engineering, Inc. / mbenn...@ideaeng.com Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513 On Thu, Aug 20, 2009 at 7:16 PM, Chris Hostetter wrote: > > : Subj

Re: Overview of Query Parsing API Stack? / Dismax parsing, new 1.4 parsing, etc.

On Thu, Aug 20, 2009 at 10:16 PM, Chris Hostetter wrote: > coming in Lucene 2.9 (which is what Solr 1.4 will use) is a completley new > QueryParser framework, which (i'm told) is suppose to make it much easier > to create custom query parser syntaxs, I've quickly looked, but haven't seen this to b

Re: Overview of Query Parsing API Stack? / Dismax parsing, new 1.4 parsing, etc.

: Subject: Overview of Query Parsing API Stack? / Dismax parsing, : new 1.4 parsing, etc. Oh, what i would give for time to sit and document in depth how some of this stuff works (assuming i first had time to verify that it really does work the way i think) The nutshell answer is that as

Re: Trouble with Shingle filter and query parsing / expansion

One other idea I tried, which didn't work, was to see if I could get proper parsing via the stream arg: http://localhost:8983/solr/mlt?stream.body=hello+world&mlt.fl=shingle_field&mlt.mintf=0&debugQuery=true On Tue, Aug 11, 2009 at 9:09 AM, Mark Bennett wrote: > I've got an index building with

Trouble with Shingle filter and query parsing / expansion

I've got an index building with the shingle filter and I can see the compound terms with Luke, etc. So far so good. One detail, I did tell it to not emit unigrams - I've got single words covered in a normal field. And a bit of poking around the other day explained why shingle queries weren't wor

Overview of Query Parsing API Stack? / Dismax parsing, new 1.4 parsing, etc.

to util classes, and to Lucene, etc. I'll get there eventually, but having a map would be nice. Another example, at the last Meetup it was mentioned that big changes are coming to query parsing pretty soon. Understanding the "before" and "after" logic would be nice, and

Re: Query Parsing in Custom Request Handler

startDate); > end = new Term("to", endDate); > RangeQuery endQuery = new RangeQuery(start, end, true); > query = new BooleanQuery(); > query.add(new BooleanClause(startQuery, BooleanClause.Occur.MUST)); > query.add(new BooleanClause(endQuery, BooleanClause.Occur.MUST)); > } > return query; > } > > private DateRange getDateRange(String text) > { > if (text == null) > return null; > else > { > DateParser p = new DateParser(); > return p.parseDateRange(text); > } > } > > } > > -- View this message in context: http://www.nabble.com/Query-Parsing-in-Custom-Request-Handler-tp21501351p21504363.html Sent from the Solr - User mailing list archive at Nabble.com.

Query Parsing in Custom Request Handler

anClause.Occur.MUST)); } return query; } private DateRange getDateRange(String text) { if (text == null) return null; else { DateParser p = new DateParser(); return p.parseDateRange(text); } } } -- View this message in context: http://www.nabble.com/Query-Parsing-in-Custom-Request-Handler-tp21501351p21501351.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: Issue with Query Parsing '+' works as 'OR'

ns don't help much. > > Lance > > -Original Message- > From: Sunil Sarje [mailto:[EMAIL PROTECTED] > Sent: Monday, October 20, 2008 9:19 PM > To: solr-user@lucene.apache.org > Subject: Issue with Query Parsing '+' works as 'OR' > > I am w

RE: Issue with Query Parsing '+' works as 'OR'

things; documentation with only technical definitions don't help much. Lance -Original Message- From: Sunil Sarje [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2008 9:19 PM To: solr-user@lucene.apache.org Subject: Issue with Query Parsing '+' works as 'OR' I am worki

  1   2   >