DIH wiki page reverted
I have reverted the DIH wiki page to revision 212. see this https://issues.apache.org/jira/browse/INFRA-2270 the wiki has not sent any mail yet So all the changes which were made after 212 is lost. Please go through the page and check if your changes are lost. -- - Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Solr 1.4 Release Date
Any news on this? Lucene 2.9 is out for some weeks now. markrmiller wrote: > > Agreed! We are pushing towards it - one of the holds up is that Lucene 2.9 > is about to release, so we are waiting for that. We really need to prune > down the JIRA list though. A few have been tackling it, but many of the > issues are still up in the air. I think once Lucene 2.9 releases though, > Solr 1.4 will shortly follow one way or another. > Lucene 2.9 is right on the verge - only a handful of pretty much finished > issues to resolve. > -- View this message in context: http://www.nabble.com/Solr-1.4-Release-Date-tp23260381p25922568.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Solr 1.4 Release Date
i was wondering the same thing since: '*NOTE: THE CURRENT GOAL IS TO START THE SOLR 1.4 RELEASE PROCESS APPROXIMATELY ONE TO TWO WEEKS AFTER LUCENE JAVA 2.9 HAS BEEN RELEASED.* ' http://wiki.apache.org/solr/Solr1.4 patiently, rob 2009/10/16 Michael R. > > Any news on this? Lucene 2.9 is out for some weeks now. > > > > markrmiller wrote: > > > > Agreed! We are pushing towards it - one of the holds up is that Lucene > 2.9 > > is about to release, so we are waiting for that. We really need to prune > > down the JIRA list though. A few have been tackling it, but many of the > > issues are still up in the air. I think once Lucene 2.9 releases though, > > Solr 1.4 will shortly follow one way or another. > > Lucene 2.9 is right on the verge - only a handful of pretty much finished > > issues to resolve. > > > -- > View this message in context: > http://www.nabble.com/Solr-1.4-Release-Date-tp23260381p25922568.html > Sent from the Solr - User mailing list archive at Nabble.com. > >
Re: Solr 1.4 Release Date
ppl will wait lucene 2.9.1 since 2.9 have a "great" bug in it. []s, Lucas Frare Teixeira .·. - lucas...@gmail.com - lucastex.com.br - blog.lucastex.com - twitter.com/lucastex On Fri, Oct 16, 2009 at 2:50 AM, Rob Ganly wrote: > i was wondering the same thing since: > > '*NOTE: THE CURRENT GOAL IS TO START THE SOLR 1.4 RELEASE PROCESS > APPROXIMATELY ONE TO TWO WEEKS AFTER LUCENE JAVA 2.9 HAS BEEN RELEASED.* ' > > http://wiki.apache.org/solr/Solr1.4 > > patiently, > > rob > > 2009/10/16 Michael R. > > > > > Any news on this? Lucene 2.9 is out for some weeks now. > > > > > > > > markrmiller wrote: > > > > > > Agreed! We are pushing towards it - one of the holds up is that Lucene > > 2.9 > > > is about to release, so we are waiting for that. We really need to > prune > > > down the JIRA list though. A few have been tackling it, but many of the > > > issues are still up in the air. I think once Lucene 2.9 releases > though, > > > Solr 1.4 will shortly follow one way or another. > > > Lucene 2.9 is right on the verge - only a handful of pretty much > finished > > > issues to resolve. > > > > > -- > > View this message in context: > > http://www.nabble.com/Solr-1.4-Release-Date-tp23260381p25922568.html > > Sent from the Solr - User mailing list archive at Nabble.com. > > > > >
Re: Solr 1.4 Release Date
You can follow the action on solr-dev. We are in code freeze right now. I'll likely put up another release candidate today. Everyone can help out by downloading either the existing RC or nightly or trunk and testing it out and providing feedback. It would also be great if people could start reading through the wiki and seeing if everything makes sense. Thanks, Grant On Oct 16, 2009, at 5:59 AM, Lucas F. A. Teixeira wrote: ppl will wait lucene 2.9.1 since 2.9 have a "great" bug in it. []s, Lucas Frare Teixeira .·. - lucas...@gmail.com - lucastex.com.br - blog.lucastex.com - twitter.com/lucastex On Fri, Oct 16, 2009 at 2:50 AM, Rob Ganly wrote: i was wondering the same thing since: '*NOTE: THE CURRENT GOAL IS TO START THE SOLR 1.4 RELEASE PROCESS APPROXIMATELY ONE TO TWO WEEKS AFTER LUCENE JAVA 2.9 HAS BEEN RELEASED.* ' http://wiki.apache.org/solr/Solr1.4 patiently, rob 2009/10/16 Michael R. Any news on this? Lucene 2.9 is out for some weeks now. markrmiller wrote: Agreed! We are pushing towards it - one of the holds up is that Lucene 2.9 is about to release, so we are waiting for that. We really need to prune down the JIRA list though. A few have been tackling it, but many of the issues are still up in the air. I think once Lucene 2.9 releases though, Solr 1.4 will shortly follow one way or another. Lucene 2.9 is right on the verge - only a handful of pretty much finished issues to resolve. -- View this message in context: http://www.nabble.com/Solr-1.4-Release-Date-tp23260381p25922568.html Sent from the Solr - User mailing list archive at Nabble.com. -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
Re: Using DIH's special commands....Help needed
Folks: Continuing my saga with DIH and use of its special commands. I have verified that the script functionality is indeed working.I also verified that '$skipRow' is working.But I don't think that '$deleteDocById' is working. My script now looks as follows: The theory is that rows whose 'IndexingStatus' value is 4 should be deleted from solr index. Just to be sure that javascript syntax was correct and checked out, I intentionally overwrite a field called 'Col1' in my schema with primary key of the document to be deleted. On a clean and empty index, I import 47 rows from my dummy db. Everything checks out correctly since IndexingStatus for each row is 1. There are no rows to delete.I then go into the db and set one row with the IndexingStatus = 4. When I execute the dataimport, I find that all 47 documents are imported correctly. However, for the row for which 'IndexingStatus' was set to 4, the Col1 value is set correctly by the script transformer to be the primary key value for that row/document. However, I should not be seeing that document since the '$deleteDocById should have deleted this from solr. Could this be a bug in solr? Or, am I misunderstanding how $deleteDocById works? By the way, Noble, I tried to set the LogTransformer, and add logging per your suggestion. That did not work either. I set logLevel="debug", and also turned on solr logging in the admin console to be the max value (finest) and still no output. Thanks, - Bill -- From: "Noble Paul ??? ??" Sent: Thursday, October 15, 2009 10:05 PM To: Subject: Re: Using DIH's special commandsHelp needed use LogTransformer to see if the value is indeed set this should print out the entire row after the transformations On Fri, Oct 16, 2009 at 3:04 AM, William Pierce wrote: Thanks for your reply! I tried your suggestion. No luck. I have verified that I have version 1.6.0_05-b13 of java installed. I am running with the nightly bits of October 7. I am pretty much out of ideas at the present timeI'd appreciate any tips/pointers. Thanks, - Bill -- From: "Shalin Shekhar Mangar" Sent: Thursday, October 15, 2009 1:42 PM To: Subject: Re: Using DIH's special commandsHelp needed On Fri, Oct 16, 2009 at 12:46 AM, William Pierce wrote: Thanks for your help. Here is my DIH config fileI'd appreciate any help/pointers you may give me. No matter what I do the documents are not getting deleted from the index. My db has rows whose 'IndexingStatus' field has values of either 1 (which means add it to solr), or 4 (which means delete the document with the primary key from SOLR index). I have two transformers running. Not sure what I am doing wrong. One thing I'd try is to use '4' for comparison rather than the number 4 (the type would depend on the sql type). Also, for javascript transformers to work, you must use JDK 6 which has javascript support. Rest looks fine to me. -- Regards, Shalin Shekhar Mangar. -- - Noble Paul | Principal Engineer| AOL | http://aol.com
lucene 2.9 bug
hello * , ive read in other threads that lucene 2.9 had a serious bug in it, hence trunk moved to 2.9.1 dev, im wondering what the bug is as ive been using the 2.9.0 version for the past weeks with no problems, is it critical to upgrade? --joe
Re: lucene 2.9 bug
Joe Calderon wrote: > hello * , ive read in other threads that lucene 2.9 had a serious bug > in it, hence trunk moved to 2.9.1 dev, im wondering what the bug is as > ive been using the 2.9.0 version for the past weeks with no problems, > is it critical to upgrade? > > --joe > http://search.lucidimagination.com/search/document/73d6f57126d9dc9b/big_bad_bug_in_lucene_2_9_0 -- - Mark http://www.lucidimagination.com
Re: lucene 2.9 bug
On Fri, Oct 16, 2009 at 11:41 AM, Joe Calderon wrote: > hello * , ive read in other threads that lucene 2.9 had a serious bug > in it, hence trunk moved to 2.9.1 dev, im wondering what the bug is as > ive been using the 2.9.0 version for the past weeks with no problems, > is it critical to upgrade? The bug can sometimes cause certain documents not to match that should have matched a query. The seriousness of the bug depends on the application. The exact conditions needed to trigger the bug are at the end of the issue: https://issues.apache.org/jira/browse/LUCENE-1974 -Yonik http://www.lucidimagination.com
RE: capitalization and delimiters
Hi Shalin I mixed up and sent the wrong schema, one that I had been testing with. I was using the same configuration as the example schema with the same results. I re-tested by re-indexing just to confirm. Also, yes I do have lowercase factory after the word delimiter. powerShot does not return the results for 'powershot' only for power and shot. If I switch lowercase factory before word delimiter, then I do get the results for powershot, but may not get the results if just searching 'power' or 'shot'. ThanksAudrey > Date: Wed, 14 Oct 2009 23:28:46 +0530 > Subject: Re: capitalization and delimiters > From: shalinman...@gmail.com > To: solr-user@lucene.apache.org > CC: au...@hotmail.com > > On Mon, Oct 12, 2009 at 9:09 PM, Audrey Foo wrote: > > > > > In my search docs, I have content such as 'powershot' and 'powerShot'. > > I would expect 'powerShot' would be searched as 'power', 'shot' and > > 'powershot', so that results for all these are returned. Instead, only > > results for 'power' and 'shot' are returned. > > Any suggestions? > > In the schema, index analyzer: > class="solr.WordDelimiterFilterFactory" generateWordParts="0" > > generateNumberParts="0" catenateWords="1" catenateNumbers="1" > > catenateAll="0"/> > > In the schema, query analyzer > class="solr.WordDelimiterFilterFactory" generateWordParts="1" > > generateNumberParts="1" catenateWords="0" catenateNumbers="0" > > catenateAll="0" splitOnCaseChange="1"/> > class="solr.LowerCaseFilterFactory"/> > > > > I find your index-time and query-time configuration very strange. Assuming > that you also have a lowercase filter, it seems that a token "powerShot" > will not be split and indexed as "powershot". Then during query, both > "power" and "shot" will match nothing. > > I suggest you start with the configuration given in the example schema. > Else, it'd be easier for us if you can help us understand the reasons behind > changing these parameters. > > -- > Regards, > Shalin Shekhar Mangar. _ New: Messenger sign-in on the MSN homepage http://go.microsoft.com/?linkid=9677403
Replication filelist command failure on container restart
Hi All, I'm facing a small problem with the replication handler: After restarting my master container (tomcat), /admin/replication/index.jsp shows me the right information, basically the same indexversion as before the restart (no commits/optimize have been done after restart): Local Index Index Version: 1255709893043, Generation: 8 However, if I query the handler with the filelist command and this version number : /replication?command=filelist&indexversion=1255709893043 , the handler gives me an error: invalid indexversion So I think my slaves will get confused if this information doesn't remain consistent after a master container restart. Is there a way to go around this problem, for instance by triggering a commit on startup (or reload) ? Thanks! Jerome. -- Jerome Eteve. http://www.eteve.net jer...@eteve.net
Re: hadoop configuarions for SOLR-1301 patch
Pravin, Hadoop allows jaring libraries into a jar under /lib. So I have my code, then put apache-solr-core-1.4-dev.jar, and all the other Solr related jars into it using "ant clean jar && jar uvf target/myhadoopsolr.jar lib/*". Then on your Hadoop cluster run something like: "/app/hadoop/bin/hadoop jar myhadoopsolr.jar com.company.HadoopSolrIndexer" As far as a more comprehensive installation instructions, like say creating a Hadoop cluster from scratch and running a this with, it will be best to start a wiki page, which I'll do shortly. -J On Thu, Oct 15, 2009 at 11:01 PM, Pravin Karne wrote: > Hi, > Patch(SOLR-1301) provides distributed indexing (using Hadoop). > > Now I have Hadoop cluster with 1 master and 2 slaves. > > Also I have applied above path to solr and build solr. > > So how I integrate above solr executables with Hadoop cluster? > > Can u please tell what are the steps for this. > > Shall I just have copy solr war to Hadoop cluster or what else ? > > (Note: I have two setup : > 1. Hadoop setup > 2. Solr setup) > > So to run distributed indexing how to bridge these two setup? > > Thanks > -Pravin > -Original Message- > From: Jason Rutherglen [mailto:jason.rutherg...@gmail.com] > Sent: Friday, October 16, 2009 7:45 AM > To: solr-user@lucene.apache.org > Subject: Re: hadoop configuarions for SOLR-1301 patch > > Hi Pravin, > > You'll need to setup a Hadoop cluster which is independent of > SOLR-1301. 1301 is for building Solr indexes only, so there > isn't a master and slave. After building the indexes one needs > to provision the indexes to Solr servers. In my case I only have > slaves because I'm not incrementally indexing on the Hadoop > generated shards. > > 1301 does need a Hadoop specific unit test, which I got started > and need to complete, that could help a little in understanding. > > -J > > On Wed, Oct 14, 2009 at 5:45 AM, Pravin Karne > wrote: >> Hi, >> I am using SOLR-1301 path. I have build the solr with given patch. >> But I am not able to configure Hadoop for above war. >> >> I want to run solr(create index) with 3 nodes (1+2) cluster. >> >> How to do the Hadoop configurations for above patch? >> How to set master and slave? >> >> >> Thanks >> -Pravin >> >> >> >> >> DISCLAIMER >> == >> This e-mail may contain privileged and confidential information which is the >> property of Persistent Systems Ltd. It is intended only for the use of the >> individual or entity to which it is addressed. If you are not the intended >> recipient, you are not authorized to read, retain, copy, print, distribute >> or use this message. If you have received this communication in error, >> please notify the sender and delete all copies of this message. Persistent >> Systems Ltd. does not accept any liability for virus infected mails. >> > > DISCLAIMER > == > This e-mail may contain privileged and confidential information which is the > property of Persistent Systems Ltd. It is intended only for the use of the > individual or entity to which it is addressed. If you are not the intended > recipient, you are not authorized to read, retain, copy, print, distribute or > use this message. If you have received this communication in error, please > notify the sender and delete all copies of this message. Persistent Systems > Ltd. does not accept any liability for virus infected mails. >
Re: Replication filelist command failure on container restart
I think you may need to tell the replication handler to enable replication after startup too? commit startup -Yonik http://www.lucidimagination.com On Fri, Oct 16, 2009 at 12:58 PM, Jérôme Etévé wrote: > Hi All, > I'm facing a small problem with the replication handler: > > After restarting my master container (tomcat), > /admin/replication/index.jsp shows me the right information, > basically the same indexversion as before the restart (no > commits/optimize have been done after restart): > > Local Index Index Version: 1255709893043, Generation: 8 > > However, if I query the handler with the filelist command and this > version number : > /replication?command=filelist&indexversion=1255709893043 , the handler > gives me an error: > > invalid indexversion > > So I think my slaves will get confused if this information doesn't > remain consistent after a master container restart. > > Is there a way to go around this problem, for instance by triggering a > commit on startup (or reload) ? > > > Thanks! > > Jerome. > > -- > Jerome Eteve. > http://www.eteve.net > jer...@eteve.net >
Which query parser handles nested queries?
Hi all, I'm trying to figure out which query parser handles nested queries (the kind documented here: http://www.lucidimagination.com/blog/2009/03/31/nested-queries-in-solr/). When working with Solr 1.3 stable, I'm able to use this syntax effectively using the default requestHandler, but when I am hand-rolling my own requestHandler, it doesn't recognize the _query_ field name. If I use the NestedQParserPlugin, I can get closer, but what I really need is to be able to combine regular Solr query syntax with a nested dismax query, and it's not clear how/whether that can be done with the NestedQParserPlugin. Seems quite possible with the default query parser that Solr uses, though. Any help would be much appreciated! Mat
Fwd: Replication filelist command failure on container restart
-- Forwarded message -- From: Jérôme Etévé Date: 2009/10/16 Subject: Re: Replication filelist command failure on container restart To: yo...@lucidimagination.com Thanks Yonik, It works now! J. 2009/10/16 Yonik Seeley : > I think you may need to tell the replication handler to enable > replication after startup too? > >commit >startup > > -Yonik > http://www.lucidimagination.com > > > On Fri, Oct 16, 2009 at 12:58 PM, Jérôme Etévé wrote: >> Hi All, >> I'm facing a small problem with the replication handler: >> >> After restarting my master container (tomcat), >> /admin/replication/index.jsp shows me the right information, >> basically the same indexversion as before the restart (no >> commits/optimize have been done after restart): >> >> Local Index Index Version: 1255709893043, Generation: 8 >> >> However, if I query the handler with the filelist command and this >> version number : >> /replication?command=filelist&indexversion=1255709893043 , the handler >> gives me an error: >> >> invalid indexversion >> >> So I think my slaves will get confused if this information doesn't >> remain consistent after a master container restart. >> >> Is there a way to go around this problem, for instance by triggering a >> commit on startup (or reload) ? >> >> >> Thanks! >> >> Jerome. >> >> -- >> Jerome Eteve. >> http://www.eteve.net >> jer...@eteve.net >> > -- Jerome Eteve. http://www.eteve.net jer...@eteve.net -- Jerome Eteve. http://www.eteve.net jer...@eteve.net
MoreLikeThis and interesting terms
Hi folks, I'm having an issue where I want MLT to operate on multiple fields, one of which contains a large number of terms (that is, each document in the index has many terms for this field) and the others only a few terms per document. In my situation, the fields with the fewer terms I am boosting, because they are what I'm particularly interested in, and the field with many terms is to be the "fallback" (so a lower boost). The problem is that because there are so many common terms in the one field across the documents in the index, MLT is returning only interesting terms from this field. If I increase the mlt.maxqt I can find the terms from the other (more important) fields, but then I have included many more terms from the already over-influencing field. Hopefully I have explained this well enough. My question is if there is a mechanism in place (I haven't been able to find one) to make those fields I have boosted the ones that come up first in the list of interesting terms. Thanks, Nick Spacek
Re: capitalization and delimiters
On Fri, Oct 16, 2009 at 9:56 PM, Audrey Foo wrote: > > Hi Shalin > I mixed up and sent the wrong schema, one that I had been testing with. > I was using the same configuration as the example schema with the same > results. I re-tested by re-indexing just to confirm. Also, yes I do have > lowercase factory after the word delimiter. > powerShot does not return the results for 'powershot' only for power and > shot. > If I switch lowercase factory before word delimiter, then I do get the > results for powershot, but may not get the results if just searching 'power' > or 'shot'. > OK, thanks for the clarification. You need to add preserveOriginal="1" to your index-time WDF configuration. This will index the original token as well as the parts so that all of "powershot", "power" and "shot" should match "powerShot". Make sure you re-index after making the changes. -- Regards, Shalin Shekhar Mangar.
Re: how can I use debugQuery if I have extended QParserPlugin?
I'm seeing the same behavior and I don't have any custom query parsing plugins. Similar to the original post, my queries like: select?q=field:[1 TO *] select?q=field:[1 TO 2] select?q=field:[1 TO 2]&debugQuery=true work correctly, but including an unboundd range appears to break the debug component: select?q=field:[1 TO *]&debugQuery=true My stack trace is the same as the original post. gdeconto wrote: > > my apologies, you are correct; I put the stack trace in an edit of the > post and not in the original post. > > re version info: > > Solr Specification Version: 1.3.0.2009.07.08.08.05.45 > Solr Implementation Version: nightly exported - yonik - 2009-07-08 > 08:05:45 > > NOTE: I have some more info on this NPE problem. I get the NPE error > whenever I use debugQuery and the query range has an asterix in it, even > tho the query itself should work. For example: > > These work ok: > > http://127.0.0.1:8994/solr/select?q=myfield:[* TO 1] > http://127.0.0.1:8994/solr/select?q=myfield:[1 TO *] > http://127.0.0.1:8994/solr/select?q=myfield:[1 TO 1000] > http://127.0.0.1:8994/solr/select?q=myfield:[1 TO 1000]&debugQuery=true > > These do not work ok: > > http://127.0.0.1:8994/solr/select?q=myfield:[* TO 1]&debugQuery=true > http://127.0.0.1:8994/solr/select?q=myfield:[1 TO *]&debugQuery=true > http://127.0.0.1:8994/solr/select?q=myfield:* > http://127.0.0.1:8994/solr/select?q=myfield:*&debugQuery=true > > Not sure if the * gets translated somewhere into a null value parameter (I > am just starting to look at the solr code) per your comment > -- View this message in context: http://www.nabble.com/how-can-I-use-debugQuery-if-I-have-extended-QParserPlugin--tp25789546p25930610.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: how can I use debugQuery if I have extended QParserPlugin?
Is this with trunk? I can't seem to reproduce this... what's the field type? -Yonik http://www.lucidimagination.com On Fri, Oct 16, 2009 at 3:01 PM, wojtekpia wrote: > > I'm seeing the same behavior and I don't have any custom query parsing > plugins. Similar to the original post, my queries like: > > select?q=field:[1 TO *] > select?q=field:[1 TO 2] > select?q=field:[1 TO 2]&debugQuery=true > > work correctly, but including an unboundd range appears to break the debug > component: > select?q=field:[1 TO *]&debugQuery=true > > My stack trace is the same as the original post. > > > gdeconto wrote: >> >> my apologies, you are correct; I put the stack trace in an edit of the >> post and not in the original post. >> >> re version info: >> >> Solr Specification Version: 1.3.0.2009.07.08.08.05.45 >> Solr Implementation Version: nightly exported - yonik - 2009-07-08 >> 08:05:45 >> >> NOTE: I have some more info on this NPE problem. I get the NPE error >> whenever I use debugQuery and the query range has an asterix in it, even >> tho the query itself should work. For example: >> >> These work ok: >> >> http://127.0.0.1:8994/solr/select?q=myfield:[* TO 1] >> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO *] >> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO 1000] >> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO 1000]&debugQuery=true >> >> These do not work ok: >> >> http://127.0.0.1:8994/solr/select?q=myfield:[* TO 1]&debugQuery=true >> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO *]&debugQuery=true >> http://127.0.0.1:8994/solr/select?q=myfield:* >> http://127.0.0.1:8994/solr/select?q=myfield:*&debugQuery=true >> >> Not sure if the * gets translated somewhere into a null value parameter (I >> am just starting to look at the solr code) per your comment >> > > -- > View this message in context: > http://www.nabble.com/how-can-I-use-debugQuery-if-I-have-extended-QParserPlugin--tp25789546p25930610.html > Sent from the Solr - User mailing list archive at Nabble.com. > >
Re: capitalization and delimiters
On Fri, Oct 16, 2009 at 2:20 PM, Shalin Shekhar Mangar wrote: > On Fri, Oct 16, 2009 at 9:56 PM, Audrey Foo wrote: > >> >> Hi Shalin >> I mixed up and sent the wrong schema, one that I had been testing with. >> I was using the same configuration as the example schema with the same >> results. I re-tested by re-indexing just to confirm. Also, yes I do have >> lowercase factory after the word delimiter. >> powerShot does not return the results for 'powershot' only for power and >> shot. >> If I switch lowercase factory before word delimiter, then I do get the >> results for powershot, but may not get the results if just searching 'power' >> or 'shot'. >> > > OK, thanks for the clarification. You need to add preserveOriginal="1" to > your index-time WDF configuration. This will index the original token as > well as the parts so that all of "powershot", "power" and "shot" should > match "powerShot". That's not the problem... the WDF config in the example server splits and catenates... no need for preserving the original. The issue is that a query of "powershot" or "power shot" would match an index with "PowerShot" or "power-shot". But if the index contains "powershot", then a query of "powerShot" will be split to "power Shot" and not match. It's a known limitation on the query side (can't both catenate and split on the query side). -Yonik http://www.lucidimagination.com
Re: Using DIH's special commands....Help needed
On Fri, Oct 16, 2009 at 5:54 PM, William Pierce wrote:
> Folks:
>
> Continuing my saga with DIH and use of its special commands. I have
> verified that the script functionality is indeed working.I also verified
> that '$skipRow' is working.But I don't think that '$deleteDocById' is
> working.
>
> My script now looks as follows:
>
>
>function DeleteRow(row) {
> var jid = row.get('Id');
>var jis = row.get('IndexingStatus');
>if ( jis == 4 ) {
> row.put('$deleteDocById', jid);
> row.remove('Col1');
> row.put('Col1', jid);
> }
> return row;
> }
> ]]>
>
>
> The theory is that rows whose 'IndexingStatus' value is 4 should be deleted
> from solr index. Just to be sure that javascript syntax was correct and
> checked out, I intentionally overwrite a field called 'Col1' in my schema
> with primary key of the document to be deleted.
>
> On a clean and empty index, I import 47 rows from my dummy db. Everything
> checks out correctly since IndexingStatus for each row is 1. There are no
> rows to delete.I then go into the db and set one row with the
> IndexingStatus = 4. When I execute the dataimport, I find that all 47
> documents are imported correctly. However, for the row for which
> 'IndexingStatus' was set to 4, the Col1 value is set correctly by the
> script transformer to be the primary key value for that row/document.
> However, I should not be seeing that document since the '$deleteDocById
> should have deleted this from solr.
>
> Could this be a bug in solr? Or, am I misunderstanding how $deleteDocById
> works?
>
>
Would the row which has IndexingStatus=4 also create a document with the
same uniqueKey which you would delete using the transformer? If yes, that
can explain what is happening and you can avoid that by adding a $skipDoc
flag in addition to the $deleteDocById flag.
I know this is a basic question but you are using Solr 1.4, aren't you?
--
Regards,
Shalin Shekhar Mangar.
Re: how can I use debugQuery if I have extended QParserPlugin?
Good catch. I was testing on a nightly build from mid-July. I just tested on a similar deployment with nightly code from Oct 5th and everything seems to work. My mid-July deployment breaks on sints, integers, sdouble, doubles, slongs and longs. My more recent deployment works with tints, sints, integers, tdoubles, sdoubles, doubles, tlongs, slongs, and longs. (I don't have any floats in my schema so I didn't test those). Sounds like another reason to upgrade to 1.4. Wojtek Yonik Seeley-3 wrote: > > Is this with trunk? I can't seem to reproduce this... what's the field > type? > > -Yonik > http://www.lucidimagination.com > > On Fri, Oct 16, 2009 at 3:01 PM, wojtekpia wrote: >> >> I'm seeing the same behavior and I don't have any custom query parsing >> plugins. Similar to the original post, my queries like: >> >> select?q=field:[1 TO *] >> select?q=field:[1 TO 2] >> select?q=field:[1 TO 2]&debugQuery=true >> >> work correctly, but including an unboundd range appears to break the >> debug >> component: >> select?q=field:[1 TO *]&debugQuery=true >> >> My stack trace is the same as the original post. >> >> >> gdeconto wrote: >>> >>> my apologies, you are correct; I put the stack trace in an edit of the >>> post and not in the original post. >>> >>> re version info: >>> >>> Solr Specification Version: 1.3.0.2009.07.08.08.05.45 >>> Solr Implementation Version: nightly exported - yonik - 2009-07-08 >>> 08:05:45 >>> >>> NOTE: I have some more info on this NPE problem. I get the NPE error >>> whenever I use debugQuery and the query range has an asterix in it, even >>> tho the query itself should work. For example: >>> >>> These work ok: >>> >>> http://127.0.0.1:8994/solr/select?q=myfield:[* TO 1] >>> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO *] >>> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO 1000] >>> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO 1000]&debugQuery=true >>> >>> These do not work ok: >>> >>> http://127.0.0.1:8994/solr/select?q=myfield:[* TO 1]&debugQuery=true >>> http://127.0.0.1:8994/solr/select?q=myfield:[1 TO *]&debugQuery=true >>> http://127.0.0.1:8994/solr/select?q=myfield:* >>> http://127.0.0.1:8994/solr/select?q=myfield:*&debugQuery=true >>> >>> Not sure if the * gets translated somewhere into a null value parameter >>> (I >>> am just starting to look at the solr code) per your comment >>> >> >> -- >> View this message in context: >> http://www.nabble.com/how-can-I-use-debugQuery-if-I-have-extended-QParserPlugin--tp25789546p25930610.html >> Sent from the Solr - User mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/how-can-I-use-debugQuery-if-I-have-extended-QParserPlugin--tp25789546p25932460.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Using DIH's special commands....Help needed
Shalin, Many thanks for your tipBut it did not seem to help! Do you think I can use postDeleteImportQuery for this task? Should I file a bug report? Cheers, Bill -- From: "Shalin Shekhar Mangar" Sent: Friday, October 16, 2009 1:16 PM To: Subject: Re: Using DIH's special commandsHelp needed On Fri, Oct 16, 2009 at 5:54 PM, William Pierce wrote: Folks: Continuing my saga with DIH and use of its special commands. I have verified that the script functionality is indeed working.I also verified that '$skipRow' is working.But I don't think that '$deleteDocById' is working. My script now looks as follows: The theory is that rows whose 'IndexingStatus' value is 4 should be deleted from solr index. Just to be sure that javascript syntax was correct and checked out, I intentionally overwrite a field called 'Col1' in my schema with primary key of the document to be deleted. On a clean and empty index, I import 47 rows from my dummy db. Everything checks out correctly since IndexingStatus for each row is 1. There are no rows to delete.I then go into the db and set one row with the IndexingStatus = 4. When I execute the dataimport, I find that all 47 documents are imported correctly. However, for the row for which 'IndexingStatus' was set to 4, the Col1 value is set correctly by the script transformer to be the primary key value for that row/document. However, I should not be seeing that document since the '$deleteDocById should have deleted this from solr. Could this be a bug in solr? Or, am I misunderstanding how $deleteDocById works? Would the row which has IndexingStatus=4 also create a document with the same uniqueKey which you would delete using the transformer? If yes, that can explain what is happening and you can avoid that by adding a $skipDoc flag in addition to the $deleteDocById flag. I know this is a basic question but you are using Solr 1.4, aren't you? -- Regards, Shalin Shekhar Mangar.
