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

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 <dradhakrishna...@gmail.com> wrote: > Hi, > > I created the following fieldType in schema.xml > > posi

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

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

to a real object, could that be lighter than parsing the incoming query text? Markus -Original message- > From:Mikhail Khludnev <m...@apache.org> > Sent: Thursday 11th May 2017 10:43 > To: solr-user <solr-user@lucene.apache.org> > Subject: How to avoid unnecessary quer

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. Until we have

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

sert 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 <max.bridgewa...@gmail.com> > wrote: > > > I am migrating a solr based app from Solr 4 to Solr 6. One of the > > dis

Re: Edismax query parsing in Solr 4 vs Solr 6

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", req).getQuery(); > > > With Solr 4, query becom

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?

nternals > >>>>> 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 OR

Re: changed query parsing between 4.10.4 and 5.5.3?

gt; >>> > >>> 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. > >

Re: changed query parsing between 4.10.4 and 5.5.3?

t; >>>>> I still get some differences in search results between 4.10.4 and >> 5.5.3. >>>>> What other side effects has this change of q.op from AND to OR in >>>>> other parts of query handling, parsing and searching? >>>>> >>>>

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

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 > >>>> > >>>> On 9 September 2

Re: changed query parsing between 4.10.4 and 5.5.3?

lt;greg.pendleb...@gmail.com >>>> >>>> wrote: >>>> >>>>> Under 4.10 q.op was ignored by the edismax parser and always forced to >>> OR. >>>>> 5.5 is looking at the q.op=AND you requested. >>>>> >>>>&g

Re: changed query parsing between 4.10.4 and 5.5.3?

. >>>> >>>> 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 <m...@apache.org> wrote: >>&g

Re: changed query parsing between 4.10.4 and 5.5.3?

ndlebury < > greg.pendleb...@gmail.com> > >> wrote: > >> > >>> Under 4.10 q.op was ignored by the edismax parser and always forced to > OR. > >>> 5.5 is looking at the q.op=AND you requested. > >>> > >>> There are

Re: changed query parsing between 4.10.4 and 5.5.3?

ly. > >> > >> On 8 September 2016 at 00:35, Mikhail Khludnev <m...@apache.org> wrote: > >> > >>> I suppose > >>>+((text:star text:trek)~2) > >>> and > >>> +(+text:star +text:trek) > >>> are equal. mm=2 is equal to

Re: changed query parsing between 4.10.4 and 5.5.3?

g it explicitly. >>> >>> On 8 September 2016 at 00:35, Mikhail Khludnev <m...@apache.org> wrote: >>> >>>> I suppose >>>>+((text:star text:trek)~2) >>>> and >>>> +(+text:star +text:trek) >>>> are e

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: >&g

Re: changed query parsing between 4.10.4 and 5.5.3?

;> +(+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

Re: 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) > > >

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?

gt; 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

Re: changed query parsing between 4.10.4 and 5.5.3?

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 +(+text:star +text:trek) There are very many new features and changes b

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

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

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

> of >>>> schemaless. It's great for indexing stuff fast, but if it guesses wrong >>>> you're stuck. >>>> >>>> >>>> So to the original problem: I'd start over and either >>>> 1> use the regular setup, not schemaless >>>

Re: query parsing

om -Original Message- From: Alessandro Benedetti [mailto:benedetti.ale...@gmail.com] Sent: 24 September 2015 09:23 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 histo

Re: query parsing

;> >>> 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 >>> solrconfig.xml file: >>> >>> >>> true >>> managed-schema &g

Re: query parsing

make several of your field definitions inside the 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]

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

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

RE: query parsing

@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 (with %0A use

Re: query parsing

; > 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 S

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

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

query parsing

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

Re: query parsing

ryNorm\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 = logtext:*deeper*, product of:\n 1.0 = boost\n 1.0 = queryNorm\n", "2012-07-11 18:1

Re: query parsing

ay through 8am EDT Sunday:\nRain is > expected basinwide. Most areas will see amounts in the 0.25 \nto 0.50 inch > range with amounts up to 0.75 inch in southeast Kentucky.\n\nQPF from > OHRFC, HPC, et al., can be seen at weather.gov/ohrfc/Forecast.php\n$$\nFor > <http://weather.gov/ohrfc/F

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: 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,

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

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

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

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

Re: SpellingQueryConverter and query parsing

@lucene.apache.org Subject: 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

RE: SpellingQueryConverter and query parsing

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! SpellingQueryConverter parses

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

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 [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

Query parsing - difference between Analysis and parsedquery_toString output

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.

Re: Query parsing - difference between Analysis and parsedquery_toString output

], 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

R: Query parsing issue

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 clauses by extending

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

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,

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.

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: Query parsing VS marshalling/unmarshalling

2012/4/24 Mindaugas Žakšauskas min...@gmail.com: 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

Re: Query parsing VS marshalling/unmarshalling

on query parsing complexity. m.

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'd be very sure

Re: Query parsing VS marshalling/unmarshalling

. [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 erickerick...@gmail.com wrote: In general, query parsing is such a small fraction of the total time

Re: Query parsing VS marshalling/unmarshalling

:43 PM, Erick Erickson erickerick...@gmail.com 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, attach debugQuery=on to your query and look at the timings in the pepare and process portions

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

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,

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

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

question about query parsing

Hi list, while searching with debug on I see strange query parsing: str name=rawquerystringidentifier:ub.uni-bielefeld.de/str str name=querystringidentifier:ub.uni-bielefeld.de/str str name=parsedquery +MultiPhraseQuery(identifier:(ub.uni-bielefeld.de ub) uni bielefeld de) /str str name

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: 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 is

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

Re: filter query parsing problem

On Tue, Jan 19, 2010 at 3:10 AM, Ahmet Arslan iori...@yahoo.com 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: arr name=filter_queries str ((VLog:814124 || VLog:12342)

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.

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.

Re: filter query parsing problem

On Wed, Jan 20, 2010 at 7:40 PM, Erik Hatcher erik.hatc...@gmail.comwrote: 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

Re: filter query parsing problem

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 recommend folks use fq={!raw f=category}Music and Electronics so that query parsing

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 iori...@yahoo.com 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: arr

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: arr name=filter_queries str ((VLog:814124 || VLog:12342) (PublisherType:U || PublisherType:A)) /str /arr arr name=parsed_filter_queries

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: arr name=filter_queries   str     ((VLog:814124 || VLog:12342) (PublisherType:U || PublisherType:A))   /str /arr arr name=parsed_filter_queries  

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

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

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

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

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:paris .

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

, the main unit of query parsing is a QParser ... lots of places in the code base may care about parsing differnet strngs for the purposes of producting a Query object, but ultimately they all use a QParser. QParsers are plugins that you can configure instances of in your solrcinfog.xml

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

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

On Thu, Aug 20, 2009 at 10:16 PM, Chris Hostetterhossman_luc...@fucit.org 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

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

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+worldmlt.fl=shingle_fieldmlt.mintf=0debugQuery=true On Tue, Aug 11, 2009 at 9:09 AM, Mark Bennett mbenn...@ideaeng.com wrote: I've got an

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

, 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 I don't recall whether that impacted just Lucene, or if Solr

Query Parsing in Custom Request Handler

{ 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: Query Parsing in Custom Request Handler

) 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

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

; 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 working with nightly build of Oct 17

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

: 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 working with nightly build of Oct 17, 2008 and found the issue that something wrong with Query Parsing; It takes + as OR e.g. q

query parsing issue + behavior as OR (solr 1.4-dev)

I am working with nightly build of Oct 17, 2008 and found the issue that something wrong with LuceneQParserPlugin; It takes + as OR e.g. q=first_name:joe+last_name:smith is behaving as OR instead of AND. Default operator is set to AND in schema.xml solrQueryParser defaultOperator=AND/ Is

Re: query parsing issue + behavior as OR (solr 1.4-dev)

On Mon, 20 Oct 2008 06:21:06 -0700 (PDT) Sunil Sarje [EMAIL PROTECTED] wrote: I am working with nightly build of Oct 17, 2008 and found the issue that something wrong with LuceneQParserPlugin; It takes + as OR Sunil, please do not hijack the thread :

  1   2   >