Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
likely, but it could be a libc bug or something). -Yonik On Thu, Apr 17, 2008 at 3:28 PM, realw5 [EMAIL PROTECTED] wrote: Hey All, I've been beating my head on this problem with no luck on finding the cause. I've done many nabble and google searches with no real solution. Let me explain the problem. First my system setup: Ubuntu 64bit Linux 6.06 Java 1.6 (amd64) (Also tried 1.5 with same results) Solr 1.2 (also tryed 1.3-dev with same results) Tomcat 6.0.16 (10 gigs of memory allocated) (also trying 5.5 with same results) Now the problem. When posting larger size documents, I am getting very random errors. I can hit refresh on the page, and the error will change on me. Here are some of those errors. The first error is the most common one, althought the second one does come up too. result status=1javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: Content is not allowed in prolog. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) at org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148) at org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) at org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) /result AND result status=1javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,8191] Message: XML document structures must start and end within the same entity. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:588) at org.apache.solr.handler.XmlUpdateRequestHandler.readDoc(XmlUpdateRequestHandler.java:318) at org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:195) at org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) at org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) /result The document I'm trying
Re: ODD Solr Error on Update POST - XMLStreamException: ParseError
threads? If so, can you just try a single one at a time? -Yonik The observed 'randomness' of the errors would be due to the unpredictable nature of the race condition between threads. The reason you don't see this with smaller documents would be that the likelihood of contention on small documents is reduced because the race is eliminated. This would also be generally independent of JVM, OS, memory allocation, etc as it seems to be. I would look into how these classes/methods are dealing with the parser factory. (keeping a static copy maybe?) org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:148) org.apache.solr.handler.XmlUpdateRequestHandler.doLegacyUpdate(XmlUpdateRequestHandler.java:386) org.apache.solr.servlet.SolrUpdateServlet.doPost(SolrUpdateServlet.java:65) This seems to me to be the most likely culprit given what I've seen so far on this thread. I hope it helps. -- Brian - Original Message From: Yonik Seeley [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Thursday, April 17, 2008 3:28:08 PM Subject: Re: ODD Solr Error on Update POST - XMLStreamException: ParseError On Thu, Apr 17, 2008 at 5:41 PM, realw5 [EMAIL PROTECTED] wrote: Ok, so I tried tomcat 5.5, still not go. It might be helpful to note, that when I decrease the size of the post (take fields out) I can get it to post without error. It seems like it's barfing on a certain file size (buffer issue maybe??). I'm running 32-bit Ubuntu on our production system and have never seen these errors. Is it possible libc has a bug only in 64-bit Ubuntu? Lastly, I can try another OS...do you have any recommendations for a good 64-bit linux flavor? Whatever you are comfortable with... if you don't already have something lying around, perhaps the latest ubuntu beta (8.04) Also double-check that you are sending exactly what you think you are. If you haven't already, capture the XML you are sending to a file, then use curl (the same version on the same box) to send the file to both the server that works and the one that doesn't. -Yonik http://www.nabble.com/file/p16758975/test_post.xml test_post.xml -- View this message in context: http://www.nabble.com/ODD-Solr-Error-on-Update-POST---XMLStreamException%3A-ParseError-tp16751961p16758975.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: SOLR 1.2 - Duplicate Documents??
I haven't made any changes to the schema since the intial full-index. Do you know if there is a way to rebuild the full index in the background, without having to take down the current live index? Dan ryantxu wrote: Schema.xml field name=id type=string indexed=true stored=true/ Have you edited schema.xml since building a full index from scratch? If so, try rebuilding the index. People often get the behavior you describe if the 'id' is a 'text' field. ryan -- View this message in context: http://www.nabble.com/SOLR-1.2---Duplicate-Documents---tf4762687.html#a13629639 Sent from the Solr - User mailing list archive at Nabble.com.
SOLR 1.2 - Duplicate Documents??
Hey all, I have a fairly odd case of duplicate documents in our solr index (See attached xml sample). THe index is roughtly 35k in documents. The only way I've found to fix the problem is to run a delete statement by id, which deletes both, I can then re-index that one document. This happened previosuly but it ended up being an issue with case-sensitivity but this time the id's appear identical! Any assistance in tracking this down would be appeciated! I can provide any other logs if nesseary. Thanks, Dan Sample Select Query: ?xml version=1.0 encoding=UTF-8 ? - response - lst name=responseHeader int name=status0/int int name=QTime0/int /lst - result name=response numFound=2 start=0 - doc - arr name=categoryId int151/int int962/int int1493/int int1830/int /arr - arr name=finish strN/A/str /arr bool name=hasDigiCastfalse/bool bool name=hasDigiVistafalse/bool str name=idhr-802waclighting/str - arr name=inStock boolfalse/bool /arr bool name=isNewfalse/bool bool name=isTopSellertrue/bool str name=manufacturerwac lighting/str - arr name=masterFinish strnot applicable/str /arr date name=modifiedDate2007-10-15T23:10:01.510Z/date bool name=onSalefalse/bool int name=popularity1683/int - arr name=price float53.91/float /arr date name=productAddDate2007-07-05T00:00:00Z/date str name=productIDHR-802/str str name=productTitleLow Voltage Miniature Housing for Recessed Lighting Fixture/str str name=serieslow voltage miniature housings/str - arr name=sku str / /arr str name=theme / - arr name=upc str / /arr /doc - doc - arr name=categoryId int151/int int962/int int1493/int int1830/int /arr - arr name=finish strN/A/str /arr bool name=hasDigiCastfalse/bool bool name=hasDigiVistafalse/bool str name=idhr-802waclighting/str - arr name=inStock boolfalse/bool /arr bool name=isNewfalse/bool bool name=isTopSellertrue/bool str name=manufacturerwac lighting/str - arr name=masterFinish strnot applicable/str /arr date name=modifiedDate2007-11-02T15:33:21.154Z/date bool name=onSalefalse/bool int name=popularity1683/int - arr name=price float53.91/float /arr date name=productAddDate2007-07-05T00:00:00Z/date str name=productIDHR-802/str str name=productTitleLow Voltage Miniature Housing for Recessed Lighting Fixture/str str name=serieslow voltage miniature housings/str - arr name=sku str / /arr str name=theme / - arr name=upc str / /arr /doc /result /response Schema.xml field name=id type=string indexed=true stored=true/ field name=sku type=textTight indexed=true stored=true multiValued=true/ field name=upc type=textTight indexed=true stored=true multiValued=true/ . !-- field to use to determine and enforce document uniqueness. -- uniqueKeyid/uniqueKey !-- field for the QueryParser to use when an explicit fieldname is absent -- defaultSearchFieldtext/defaultSearchField !-- SolrQueryParser configuration: defaultOperator=AND|OR -- solrQueryParser defaultOperator=OR/ -- View this message in context: http://www.nabble.com/SOLR-1.2---Duplicate-Documents---tf4762687.html#a13621332 Sent from the Solr - User mailing list archive at Nabble.com.
Re: DisMax request handler doesn't work with stopwords?
I'm having the same issues. We are using Dismax, with a stopword list. Currently we are having customers typing in model ipod, we added model to the stopwords list and tested with the standard handler..works fine, but not with dismax (MM = 3lt;-1 5lt;-2 6lt;90%). When i comment out MM, it works. Do you have any recommendations on how to deal with this issue, without doing away with MM (MM does help with alot of phrase queries). Thanks, Dan Casey Durfee wrote: It appears that if your search terms include stopwords and you use the DisMax request handler, you get no results whereas the same search with the standard request handler does give you results. Is this a bug or by design? Thanks, --Casey -- View this message in context: http://www.nabble.com/DisMax-request-handler-doesn%27t-work-with-stopwords--tf3886305.html#a2461 Sent from the Solr - User mailing list archive at Nabble.com.
Facet Results Strange - Help
Hello, I'm running into some strange results for some facets of mine. Below you'll see the XML returned from solr. I did a query using the standard request handler. Notice the duplicated values returned (american standard, delta, etc). There is actually quite a few of them. At first I though it may be because of case sensitivity, but I since lower case everything going to solr. Hopefully someone can chime in with some tips, thanks! Dan ?xml version=1.0 encoding=UTF-8 ? - response - lst name=responseHeader int name=status0/int int name=QTime4/int /lst result name=response numFound=2328 start=0 / - lst name=facet_counts lst name=facet_queries / - lst name=facet_fields - lst name=manufacturer_facet int name=kohler1560/int int name=american standard197/int int name=toto181/int int name=bemis83/int int name=porcher56/int int name=ginger45/int int name=elements of design40/int int name=brasstech18/int int name=st thomas18/int int name=hansgrohe15/int int name=sterling14/int int name=whitehaus13/int int name=delta12/int int name=jacuzzi10/int int name=cifial8/int int name=kwc8/int int name=herbeau7/int int name=jado7/int int name=elizabethan classics6/int int name=showhouse by moen5/int int name=grohe4/int int name=creative specialties3/int int name=latoscana3/int int name=american standard2/int int name=danze2/int int name=ronbow2/int int name=belle foret1/int int name=dornbracht1/int int name=kohler1/int int name=myson1/int int name=newport brass1/int int name=price pfister1/int int name=quayside publishing1/int int name=st. thomas1/int int name=adagio0/int int name=alno0/int int name=alsons0/int int name=bates and bates0/int int name=blanco0/int int name=cec0/int int name=cole and co0/int int name=competitive0/int int name=corstone0/int int name=creative specialties0/int int name=danze0/int int name=decolav0/int int name=dolan designs0/int int name=doralfe0/int int name=dornbracht0/int int name=dreamline0/int int name=elkay0/int int name=fontaine0/int int name=franke0/int int name=grohe0/int int name=hamat0/int int name=hydrosystems0/int int name=improvement direct0/int int name=insinkerator0/int int name=kenroy international0/int int name=kichler0/int int name=kindred0/int int name=maxim0/int int name=mico0/int int name=moen0/int int name=moen0/int int name=mr sauna0/int int name=mr steam0/int int name=neo elements0/int int name=newport brass0/int int name=ondine0/int int name=pegasus0/int int name=price pfister0/int int name=progress lighting0/int int name=pulse0/int int name=quoizel0/int int name=robern0/int int name=rohl0/int int name=sagehill designs0/int int name=sea gull lighting0/int int name=show house0/int int name=sloan0/int int name=st%2e thomas0/int int name=st%2e thomas creations0/int int name=steamist0/int int name=swanstone0/int int name=thomas lighting0/int int name=warmatowel0/int int name=waste king0/int int name=waterstone0/int /lst /lst /lst /response -- View this message in context: http://www.nabble.com/Facet-Results-Strange---Help-tf3658597.html#a1084 Sent from the Solr - User mailing list archive at Nabble.com.
Re: Facet Results Strange - Help
I have a dynamic field setup for facets. It looks like this: dynamicField name=*_facet type=string indexed=true stored=false multiValued=true / I do this, because we add facets quite often, so having to modify the schema every time would be unfeasible. I'm currently reindexing from scratch, so I cannot try wt=python for little bit longer. Once it's done indexing I'll give that a go and see if I notice anything. Dan Yonik Seeley wrote: On 4/27/07, realw5 [EMAIL PROTECTED] wrote: Hello, I'm running into some strange results for some facets of mine. Below you'll see the XML returned from solr. I did a query using the standard request handler. Notice the duplicated values returned (american standard, delta, etc). There is actually quite a few of them. At first I though it may be because of case sensitivity, but I since lower case everything going to solr. Hopefully someone can chime in with some tips, thanks! What's the field definition for manufacturer_facet in your schema? Is it multi-valued or not? Also, can you try the python response format (wt=python) as it outputs only ASCII and escapes everything else... there is an off chance the strings look the same but aren't. -Yonik -- View this message in context: http://www.nabble.com/Facet-Results-Strange---Help-tf3658597.html#a10226359 Sent from the Solr - User mailing list archive at Nabble.com.
Re: Facet Results Strange - Help
Ok, I just finished indexing about 20k in documents. I took a look at so far the problem has not appearred again. What I'm thinking caused it was I was not adding overwritePending overwriteCommited in the add process. Therefor over time as data was being cleaned up, it was just appending to the existing data. I did have once cause of repeated values, but after looking at the python writer, I notice a space at the end. I can fix this issue by triming all my values before sening them to solr :-) I'm going to continue indexing, and if the problem popups up once fully indexed I'll post back again. Otherwise thanks for the quick replies! Dan Yonik Seeley wrote: On 4/27/07, realw5 [EMAIL PROTECTED] wrote: I have a dynamic field setup for facets. It looks like this: dynamicField name=*_facet type=string indexed=true stored=false multiValued=true / I do this, because we add facets quite often, so having to modify the schema every time would be unfeasible. I'm currently reindexing from scratch, so I cannot try wt=python for little bit longer. Once it's done indexing I'll give that a go and see if I notice anything. If it's really the same field value repeated, you've hit a bug. If so, it would be helpful if you could open a JIRA bug, and anything you can do to help us reproduce the problem would be appreciated. -Yonik -- View this message in context: http://www.nabble.com/Facet-Results-Strange---Help-tf3658597.html#a10226731 Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr Scripts.conf Parsing Error
I have not run bash -x, however I have run rsyncd-enable with -V which shows all the debug output. Here, is a snip of that. Note the solr\r, yet in my .conf file I have only user=solr. If I run the script using this command ./solr/bin/rsyncd-enable -u solr -V everything works fine. Also, if this helps, I'm running Red Hat ES 4. [EMAIL PROTECTED] apache-tomcat]# ./solr/bin/rsyncd-enable -V + ./solr/bin/rsyncd-enable -V + fixUser -V ]][ -z solr ++ whoami ]][ root != solr + sudo -u $'solr\r' ./solr/bin/rsyncd-enable -V !udo: no passwd entry for solr + exit 1 ++ echo -ne '\033]0;[EMAIL PROTECTED]:/usr/local/apache-tomcat\007' Dan Bill Au wrote: What does your directory structure looks like? Have you tried running rsyncd-enable with bash -x to see how/what $user is set? Bill On 4/9/07, realw5 [EMAIL PROTECTED] wrote: Hello, I'm having troubles getting replication to work using the supplied solr scripts. I've been doing alot of digging today, going though all the bash scripts that make all this happen using rsync. I'm pretty sure I've boiled it down to the scripts.conf file. When I make my settings in this file and try to run say rsyncd-enable, I get an error saying no passwd for user solr. But yet, when I pass in the argument -u solr, it works just fine! My though is the scripts.conf file has bad line characters or something along those lines, however when I check it out in VI, I see nothing odd. Any help would be appeciated! This is my last step to an otherwise successful solr setup. Dan my scripts.conf file: # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the License); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an AS IS BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. user=solr solr_hostname=localhost solr_port=8080 rsyncd_port=18080 data_dir= webapp_name=solr master_host= master_data_dir= master_status_dir= -- View this message in context: http://www.nabble.com/Solr-Scripts.conf-Parsing-Error-tf3550726.html#a9912973 Sent from the Solr - User mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/Solr-Scripts.conf-Parsing-Error-tf3550726.html#a9943326 Sent from the Solr - User mailing list archive at Nabble.com.
Solr Scripts.conf Parsing Error
Hello, I'm having troubles getting replication to work using the supplied solr scripts. I've been doing alot of digging today, going though all the bash scripts that make all this happen using rsync. I'm pretty sure I've boiled it down to the scripts.conf file. When I make my settings in this file and try to run say rsyncd-enable, I get an error saying no passwd for user solr. But yet, when I pass in the argument -u solr, it works just fine! My though is the scripts.conf file has bad line characters or something along those lines, however when I check it out in VI, I see nothing odd. Any help would be appeciated! This is my last step to an otherwise successful solr setup. Dan my scripts.conf file: # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the License); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an AS IS BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. user=solr solr_hostname=localhost solr_port=8080 rsyncd_port=18080 data_dir= webapp_name=solr master_host= master_data_dir= master_status_dir= -- View this message in context: http://www.nabble.com/Solr-Scripts.conf-Parsing-Error-tf3550726.html#a9912973 Sent from the Solr - User mailing list archive at Nabble.com.
Solr DisMax and 'New' DateField query syntax
First off, solr has done nothing but wonders for me! So let me give everyone envolved a big cheers! Recently I discovered the 'new' DateField syntax options which allow [NOW/DAY-1MONTH] type querys. However when going to try out this I found a possible bug (or maybe I'm just missing something) when using it in junction with the DisMaxRequestHandler. Can anyone point me in the right direction or confirm it's a bug for me. Below is the error. Currently I'm speficing a fq query like so: fq=timestamp:[NOW/DAY-1MONTH] Here is the error I get: org.apache.lucene.queryParser.ParseException: Cannot parse 'timestamp:[NOW/DAY-1MONTH]': Encountered ] at line 1, column 25. Was expecting one of: TO ... ... ... at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:127) at org.apache.solr.request.SimpleFacets.getFacetQueryCounts(SimpleFacets.java:112) at org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:81) at org.apache.solr.request.DisMaxRequestHandler.getFacetInfo(DisMaxRequestHandler.java:416) at org.apache.solr.request.DisMaxRequestHandler.handleRequest(DisMaxRequestHandler.java:342) at org.apache.solr.core.SolrCore.execute(SolrCore.java:595) at org.apache.solr.servlet.SolrServlet.doGet(SolrServlet.java:92) at org.apache.solr.servlet.SolrServlet.doPost(SolrServlet.java:83) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Thanks, Dan -- View this message in context: http://www.nabble.com/Solr-DisMax-and-%27New%27-DateField-query-syntax-tf3256448.html#a9053683 Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr DisMax and 'New' DateField query syntax
Duuh! Stupid me. I didn't even try that. Thanks for such a quick replay. That should solve my problem..Thanks Hoss!! Chris Hostetter wrote: the square brackets raen't anything new ... they are the standard Lucene QUeryParser syntax for range queries, which have hte syntax... field:[low TO high] in conjuntion with the new DateMath, you need something along the lines of... timestamp:[NOW/DAY-1MONTH TO NOW/DAY+1DAY] ...assuming your goal is to find timestamps in the past month. i used NOW/DAY+1DAY as the upper bound instead of NOW so it will have the same day granularity as the lower bound (good for caching) and won't miss things added today. : Recently I discovered the 'new' DateField syntax options which allow : [NOW/DAY-1MONTH] type querys. However when going to try out this I found a : possible bug (or maybe I'm just missing something) when using it in junction : with the DisMaxRequestHandler. Can anyone point me in the right direction or : confirm it's a bug for me. Below is the error. : : Currently I'm speficing a fq query like so: : : fq=timestamp:[NOW/DAY-1MONTH] -Hoss -- View this message in context: http://www.nabble.com/Solr-DisMax-and-%27New%27-DateField-query-syntax-tf3256448.html#a9053873 Sent from the Solr - User mailing list archive at Nabble.com.