Delete from web interface?
Hi, I'm using solr 1.4. It seems that I can only do queries from the web interface. To post and delete, I'd have to drop to command line using the post script or command line or write some code. It'd be really great if the web interface could be extended and add a form to take XML content for posting, and a field for delete by query. This would be extremely useful during debugging where test data is inserted and deleted all the time, and often manually. Just a suggestion.
Does MoreLikeThis support sharding?
Hi, I tried MoreLikeThis (StandardRequestHandler with mlt arguments) with a single solr server and it works fine. However, when I tried the same query with sharded servers, I don't get the moreLikeThis key in the results. So my question is, Is MoreLikeThis with StandardRequestHandler supported on shards? If not, is MoreLikeThisHandler supported? Thanks, Jack
Re[2]: Does MoreLikeThis support sharding?
>> So my question is, Is MoreLikeThis with StandardRequestHandler >> supported on shards? If not, is MoreLikeThisHandler supported? > No, MoreLikeThis does not work with distributed search currently. > There is an issue open with a couple of patches though. > See https://issues.apache.org/jira/browse/SOLR-788 Ah, I see. Thanks. Is it a part of the 1.4 plan to add this support?
Re: Any new python libraries?
I used it with 1.2 but had some unicode issues. Anyone else has had issues with unicode? Or maybe the issues have been addressed ? On Mon, Dec 22, 2008 at 7:04 PM, Ed Summers wrote: > On Mon, Dec 22, 2008 at 4:53 AM, Mark Jarecki wrote: >> I was just wondering if there were any new Python libraries compatible with >> SOLR 1.3 available or in development? All I can find are libraries for 1.2. > > Did you see: > > http://code.google.com/p/solrpy/ > > I'm using it with v1.3 > > //Ed >
Re: Any new python libraries?
Maybe I'm using an older version. I'll give it a try and report back. Thanks. On Tue, Dec 23, 2008 at 3:26 AM, Ed Summers wrote: > Yes I've used it with Unicode, see test_unicode in the unittests [1]. > In fact one of the reasons why it was moved to google-code was so we > could rapidly fix some of the outstanding problems with the python > client. If you can demonstrate a bug using the unittests we've got for > it that would be great. > > //Ed > > [1] http://code.google.com/p/solrpy/source/browse/trunk/tests/test_all.py >
Store fields that are not defined in schema?
I haven't tried this but is it possible to store fields that are not defined in solr schema and retrieve them in the result? I understand there could be conflicts in terms of how each document understand/defines these fields but since these fields are not defined, and thus not index, it should cause no trouble to the solr engine. So these fields would become document-local. This sounds useful in the case where multiple doc types are indexed in the same index.
Re: Store fields that are not defined in schema?
Thanks Otis, for the quick reply. I see. I haven't used Payload before. Is it new in 1.3? So if I have documents that have very different fields, I should use an external document storage, such as CouchDB, and only store the indexed fields in Solr? Is this a recommended set up? How does this compare with using Payload? I'm assuming payload will be stored on disk only and will not affect indexing and searching performance. On Sun, Mar 8, 2009 at 11:54 AM, Otis Gospodnetic wrote: > > Hello, > > All fields you want to index or store in the index must be defined in the > Solr schema. If you prefer having schemaless indices, that's where straight > Lucene without Solr can be helpful. You can store additional information for > each term, though. This is known as "Payload". Perhaps that is how you can > sneak in additional data in your documents. > > > Otis-- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > - Original Message >> From: jlist9 >> To: solr-user@lucene.apache.org >> Sent: Sunday, March 8, 2009 2:33:03 PM >> Subject: Store fields that are not defined in schema? >> >> I haven't tried this but is it possible to store fields that are not >> defined in solr schema and retrieve them in the result? >> >> I understand there could be conflicts in terms of how each document >> understand/defines these fields but since these fields are not >> defined, and thus not index, it should cause no trouble to the solr >> engine. So these fields would become document-local. >> >> This sounds useful in the case where multiple doc types are indexed in >> the same index. > >
Re: Store fields that are not defined in schema?
Thanks again. I personally would think putting the doc in payload is cleaner because I'd have one less system to worry about. But if payload is one big field, retrieving specific fields would require additional parsing. Other than this, is there any reason I should not put the document in payload? On Sun, Mar 8, 2009 at 12:02 PM, Otis Gospodnetic wrote: > > Combining Lucene/Solr with an external document storage system is common. > CouchDB, BDB, etc. are all fine candidates. > Payloads are relatively new, yes. Storing fields in an external storage > system is the cleaner way to go. > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > - Original Message >> From: jlist9 >> To: solr-user@lucene.apache.org >> Sent: Sunday, March 8, 2009 2:59:50 PM >> Subject: Re: Store fields that are not defined in schema? >> >> Thanks Otis, for the quick reply. >> >> I see. I haven't used Payload before. Is it new in 1.3? >> >> So if I have documents that have very different fields, I should >> use an external document storage, such as CouchDB, and only >> store the indexed fields in Solr? Is this a recommended set up? >> How does this compare with using Payload? I'm assuming payload >> will be stored on disk only and will not affect indexing and searching >> performance. >> >> On Sun, Mar 8, 2009 at 11:54 AM, Otis Gospodnetic >> wrote: >> > >> > Hello, >> > >> > All fields you want to index or store in the index must be defined in the >> > Solr >> schema. If you prefer having schemaless indices, that's where straight >> Lucene >> without Solr can be helpful. You can store additional information for each >> term, though. This is known as "Payload". Perhaps that is how you can >> sneak in >> additional data in your documents. >> > >> > >> > Otis-- >> > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch >> > >> > >> > >> > - Original Message >> >> From: jlist9 >> >> To: solr-user@lucene.apache.org >> >> Sent: Sunday, March 8, 2009 2:33:03 PM >> >> Subject: Store fields that are not defined in schema? >> >> >> >> I haven't tried this but is it possible to store fields that are not >> >> defined in solr schema and retrieve them in the result? >> >> >> >> I understand there could be conflicts in terms of how each document >> >> understand/defines these fields but since these fields are not >> >> defined, and thus not index, it should cause no trouble to the solr >> >> engine. So these fields would become document-local. >> >> >> >> This sounds useful in the case where multiple doc types are indexed in >> >> the same index. >> > >> > > >
Embed my webapp in solr jetty
Is it a bad idea to embed my webapp in solr jetty? Or is it always better to use a separate web server if I'm serving the result from a web server? Thanks
Question about MoreLikeThis
Hi, I have a question about what MoreLikeThis means - I suppose it means "get more documents that are similar to _this_ document". So I expect the query always take a known document as argument. I wonder how I should interpret this query: http://localhost:8983/solr/select?q=apache&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mintf=1&fl=id,score It doesn't seem to specify a document. So what's the "This" in MoreLikeThis in this case? Or, "this" means something else, and not a document?
Fwd: Question about MoreLikeThis
I think I understand it now. It means to return MoreLikeThis docs for every doc in the result. ===8<==Original message text=== Hi, I have a question about what MoreLikeThis means - I suppose it means "get more documents that are similar to _this_ document". So I expect the query always take a known document as argument. I wonder how I should interpret this query: http://localhost:8983/solr/select?q=apache&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mintf=1&fl=id,score It doesn't seem to specify a document. So what's the "This" in MoreLikeThis in this case? Or, "this" means something else, and not a document?
Highlight MoreLikeThis results?
My query returns a number of MoreLikeThis results for a given document. I wonder if there is a way to highlight the terms in the MoreLikeThis results? Thanks.
Re[2]: Highlight MoreLikeThis results?
I see. Thanks. > There was a thread about this last week and verdict is currently you > can't highlight MoreLikeThis results. > Thanks, > Matt Weber >> My query returns a number of MoreLikeThis results for a given >> document. I wonder if there is a way to highlight the terms >> in the MoreLikeThis results? Thanks.
Slow Post Performance
I have an index of about 6 million small documents. I find that after a few days of on and off posting, searching still works fine but posting gets really slow - client http connection always times out. I restarted server. Then posting speed seemed to have returned to normal. Is this the expected behavior? Should I start considering sharking my data? I didn't think 6 million was a large number for one instance of solr but I'd like to know others' experience. Thanks!
Re: Slow Post Performance
I'm using the embedded Jetty. >> I have an index of about 6 million small documents. >> I find that after a few days of on and off posting, searching >> still works fine but posting gets really slow - client http >> connection always times out. I restarted server. Then posting >> speed seemed to have returned to normal. Is this the expected >> behavior? > > Definitely not... what servlet container are you using? > > -Yonik
start param for MoreLikeThis?
Hi. I'm using the StandardRequestHandler for MoreLikeThis queries. I find that although I can specify how many results I want returned with mlt.count, it seesm like I can not specify a start location so that I can paginate the results. Is this the case? Thanks
Re: Solr memory requirements?
I've never paid attention to post/commit ration. I usually do a commit after maybe 100 posts. Is there a guideline about this? Thanks. On Wed, May 13, 2009 at 1:10 PM, Otis Gospodnetic wrote: > 2) ramBufferSizeMB dictates, more or less, how much Lucene/Solr will consume > during indexing. There is no need to commit every 50K docs unless you want > to trigger snapshot creation.
Getting 404 for MoreLikeThis handler
Hi, I'm trying out the mlt handler but I'm getting a 404 error. HTTP Status 404 - /solr/mlt solrconfig.xml seem to say that mlt handler is available by default. i wonder if there's anything else I should do before I can use it? I'm using version 1.3. Thanks
More questions about MoreLikeThis
The wiki page (http://wiki.apache.org/solr/MoreLikeThis) says: mlt.fl: The fields to use for similarity. NOTE: if possible, these should have a stored TermVector I didn't set TermVector to true MoreLikeThis with StandardRequestHandler seems to work fine. The first question is, is TermVector only for performance optimization? The second question is, afterI changed the mlt.fl fields from both indexed and stored to indexed only, I started to get zero results back. Do mlt.fl fields always need to be stored? Thanks
Re: Getting 404 for MoreLikeThis handler
Thanks. Will that still be the MoreLikeThisRequestHandler? Or the StandardRequestHandler with mlt option? >> Hi, I'm trying out the mlt handler but I'm getting a 404 error. >> >> HTTP Status 404 - /solr/mlt >> >> solrconfig.xml seem to say that mlt handler is available by default. >> i wonder if there's anything else I should do before I can use it? >> I'm using version 1.3. > > Try /solr/select with mlt=on parameter. > > Koji
Re: More questions about MoreLikeThis
Thanks. That explains it! I'll set termVector to true and give it a try again. On Mon, May 25, 2009 at 7:41 AM, Koji Sekiguchi wrote: > MLT uses termVector if it exists for the field. If termVector is not > available, > MLT tries to get stored field data. If stored field is not available, MLT > does nothing for the field as you were seeing. > > So mlt.fl fields don't always need to be stored.
Solr on Tomcat, how to use an external data directory?
My solr index works fine with the embedded Jetty. I'm trying to move the index to Tomcat. Following the wiki page http://wiki.apache.org/solr/SolrTomcat, I put this line in setenv.bat: set JAVA_OPTS=%JAVA_OPTS% "-Dfile.encoding=UTF-8" "-Dsolr.solr.home=D:\opt\solr\example" Tomcat seems to be picking it up. If I point it to a non-existent directory or an empty directory, Tomcat complains about it in console log. However, the /solr/admin/stats.jsp page still shows that solr is using a default directory, which is unsurprisingly located in tomcat bin dir: readerDir : org.apache.lucene.store.simplefsdirect...@d:\Java\apache-tomcat-6.0.20\bin\solr\data\index Any idea what else I need to do to use an external solr index directory in Tomcat? Thanks, Jack
Re: Solr on Tomcat, how to use an external data directory?
I only have one solr instance so I followed the "Single Solr Instance", which basically tells me to set -Dsolr.solr.home to the solr directory, which I did ... On Sat, May 29, 2010 at 2:32 PM, K Wong wrote: > There are directions on this page under Tomcat on Windows > Multiple Solr > apps: > > http://wiki.apache.org/solr/SolrTomcat > > I'm running a multicore install on RHEL5/Tomcat5.5 and I just followed > the docs and it went fine. I'm not sure that I can be of much help > other than pointing you to the relevant docs, since I am not running > this on Windows. > > K > > > > On Sat, May 29, 2010 at 1:48 PM, jlist9 wrote: >> My solr index works fine with the embedded Jetty. I'm trying to move the >> index to Tomcat. Following the wiki page >> http://wiki.apache.org/solr/SolrTomcat, >> I put this line in setenv.bat: >> >> set JAVA_OPTS=%JAVA_OPTS% "-Dfile.encoding=UTF-8" >> "-Dsolr.solr.home=D:\opt\solr\example" >> >> Tomcat seems to be picking it up. If I point it to a non-existent >> directory or an empty >> directory, Tomcat complains about it in console log. >> >> However, the /solr/admin/stats.jsp page still shows that solr is using a >> default >> directory, which is unsurprisingly located in tomcat bin dir: >> >> readerDir : >> org.apache.lucene.store.simplefsdirect...@d:\Java\apache-tomcat-6.0.20\bin\solr\data\index >> >> Any idea what else I need to do to use an external solr index >> directory in Tomcat? >> >> Thanks, >> Jack >> >
Re: Solr on Tomcat, how to use an external data directory?
Thanks! I tried that and it worked. It turned out that I also need to set -Dsolr.data.dir=/opt/solr/example/data On Sat, May 29, 2010 at 3:07 PM, Abdelhamid ABID wrote: > Most likely you have missed to point data directory in solrconf.xml, > this should help : > http://wiki.apache.org/solr/SolrConfigXml#dataDir_parameter > > On Sat, May 29, 2010 at 9:48 PM, jlist9 wrote: > >> My solr index works fine with the embedded Jetty. I'm trying to move the >> index to Tomcat. Following the wiki page >> http://wiki.apache.org/solr/SolrTomcat, >> I put this line in setenv.bat: >> >> set JAVA_OPTS=%JAVA_OPTS% "-Dfile.encoding=UTF-8" >> "-Dsolr.solr.home=D:\opt\solr\example" >> >> Tomcat seems to be picking it up. If I point it to a non-existent >> directory or an empty >> directory, Tomcat complains about it in console log. >> >> However, the /solr/admin/stats.jsp page still shows that solr is using a >> default >> directory, which is unsurprisingly located in tomcat bin dir: >> >> readerDir : org.apache.lucene.store.simplefsdirect...@d >> :\Java\apache-tomcat-6.0.20\bin\solr\data\index >> >> Any idea what else I need to do to use an external solr index >> directory in Tomcat? >> >> Thanks, >> Jack >> > > > > -- > Abdelhamid ABID > Software Engineer- J2EE / WEB >
Re: Solr on Tomcat, how to use an external data directory?
You are right. Thanks Chris! On Sat, May 29, 2010 at 4:15 PM, Chris Hostetter wrote: > > : Most likely you have missed to point data directory in solrconf.xml, > : this should help : > : http://wiki.apache.org/solr/SolrConfigXml#dataDir_parameter > > right .. double check what the dataDir setting looks like ... if it's > unset it uses "data" in your solr instance directory, but if it is set, > it's (unfortunately) evaluated relative to the "current working directory" > of your servlet container and some versions of solr had "./data" listed in > the example solrconfig.xml > > > > -Hoss > >
Luke browser does not show non-String Solr fields?
I tried the stand-alone Luke tool (not Luke request handler) to browse a solr index and find a few strange things: 1. Queries like "id:123" which work fine in /solr/admin web interface returns nothing in Luke. "*:*" returns everything fine in Luke. 2. When Luke displays records with query "*:*", it shows the string values fine but the numeric fields and date fields shows blank. It shows DocID OK, though. Anyone else has tried Luke on a solr index?
Re: Luke browser does not show non-String Solr fields?
I find in the Plugins tab that the default is PersianAnalyzer. I switched to StandardAnalyzer and tried a few different Lucene Compatibility values but it didn't help :-( On Sun, May 30, 2010 at 4:40 AM, Erick Erickson wrote: > The Solr admin page as access to (and uses) the field > definitions you've put in the config file. Luke has no > knowledge of this configuration, you have to choose > your analyzer from the drop down and select the one > closest to what's in your config file for SOLR. Are you > perhaps using an analyzer in Luke that doesn't > play nice with the definitions in SOLR? > > HTH > Erick > > > On Sat, May 29, 2010 at 10:55 PM, jlist9 wrote: > >> I tried the stand-alone Luke tool (not Luke request handler) to browse >> a solr index and find a few strange things: >> >> 1. Queries like "id:123" which work fine in /solr/admin web interface >> returns nothing in Luke. "*:*" returns everything fine in Luke. >> >> 2. When Luke displays records with query "*:*", it shows the string >> values fine but the numeric fields and date fields shows blank. It shows >> DocID OK, though. >> >> Anyone else has tried Luke on a solr index? >> >
Re: Solr on Tomcat, how to use an external data directory?
The JVM arg seems to overwrite that just fine:
-Dsolr.data.dir=/opt/solr/example/data
On Sun, May 30, 2010 at 12:14 AM, Abdelhamid ABID wrote:
> .. and to unset dataDir just leave it blank
> ${solr.data.dir:}
>
> On Sun, May 30, 2010 at 12:15 AM, Chris Hostetter
> wrote:
>
>>
>> : Most likely you have missed to point data directory in solrconf.xml,
>> : this should help :
>> : http://wiki.apache.org/solr/SolrConfigXml#dataDir_parameter
>>
>> right .. double check what the dataDir setting looks like ... if it's
>> unset it uses "data" in your solr instance directory, but if it is set,
>> it's (unfortunately) evaluated relative to the "current working directory"
>> of your servlet container and some versions of solr had "./data" listed in
>> the example solrconfig.xml
>>
>>
>>
>> -Hoss
>>
>>
>
>
> --
> Abdelhamid ABID
> Software Engineer- J2EE / WEB
>
Re: Luke browser does not show non-String Solr fields?
Oh, here's a modified/improved version of what I described in my first email: 1. Queries like "id:123" which work fine in /solr/admin web interface but returns nothing in Luke. Query "*:*" returns all records fine in Luke. I expect Luke returns the same result as /solr/admin since it's essentially a Lucene query? 2. When Luke displays records with query "*:*", it shows the string values fine but the numeric fields and date fields show blank. It shows DocID OK, though. I expect Luke to be able to show non-string values, too. On Sun, May 30, 2010 at 10:57 AM, Erick Erickson wrote: > Then you have to provide a lot more detail about what you did > and what you're seeing and what you think you should see. You > might review this page: > http://wiki.apache.org/solr/UsingMailingLists > > Best > Erick > > On Sun, May 30, 2010 at 1:41 PM, jlist9 wrote: > >> I find in the Plugins tab that the default is PersianAnalyzer. I switched >> to StandardAnalyzer and tried a few different Lucene Compatibility values >> but it didn't help :-( >> >> On Sun, May 30, 2010 at 4:40 AM, Erick Erickson >> wrote: >> > The Solr admin page as access to (and uses) the field >> > definitions you've put in the config file. Luke has no >> > knowledge of this configuration, you have to choose >> > your analyzer from the drop down and select the one >> > closest to what's in your config file for SOLR. Are you >> > perhaps using an analyzer in Luke that doesn't >> > play nice with the definitions in SOLR? >> > >> > HTH >> > Erick >> > >> > >> > On Sat, May 29, 2010 at 10:55 PM, jlist9 wrote: >> > >> >> I tried the stand-alone Luke tool (not Luke request handler) to browse >> >> a solr index and find a few strange things: >> >> >> >> 1. Queries like "id:123" which work fine in /solr/admin web interface >> >> returns nothing in Luke. "*:*" returns everything fine in Luke. >> >> >> >> 2. When Luke displays records with query "*:*", it shows the string >> >> values fine but the numeric fields and date fields shows blank. It shows >> >> DocID OK, though. >> >> >> >> Anyone else has tried Luke on a solr index? >> >> >> > >> >
Re: Luke browser does not show non-String Solr fields?
Sorry. Let me add more info. (I assumed that anyone who tried it would see the problem right away but that might not be the case.) > You haven't shown the SOLR field type definitions. Values of all non-String types in my index are not being shown. In my case, this includes long, tint and date types. > You haven't provided, say, the output from SOLR if you add &debugQuery=on. Solr side of things seem to work fine. Is this still needed? > You haven't shown the terms from either SOLR admin or Luke that they > actually see in the index. I'm not sure if I understand this question. Basically, if I do a query "id:694" in /solr/admin, I get the result. But the same query doesn't return anything in Luke. > You haven't identified the version of SOLR that the index was created with Solr 1.4 > You haven't identified the version of Luke you're using. Luke 1.0.1 (2010-04-01) > Both SOLR and Luke use Lucene under the covers, so the problem is almost > certainly your expectations... This may well be the case. Not knowing the details, I was still surprised since I expected the same search behavior for simple queries between solr and luke. > Imagine a co-worker from another department has provided you the information > you've provided us. What could you say? I might give it a try and see the same thing :-D Thanks > On Sun, May 30, 2010 at 2:19 PM, jlist9 wrote: > >> Oh, here's a modified/improved version of what I described in my first >> email: >> >> 1. Queries like "id:123" which work fine in /solr/admin web interface but >> returns nothing in Luke. Query "*:*" returns all records fine in Luke. I >> expect Luke returns the same result as /solr/admin since it's essentially >> a Lucene query? >> >> 2. When Luke displays records with query "*:*", it shows the string >> values fine but the numeric fields and date fields show blank. It shows >> DocID OK, though. I expect Luke to be able to show non-string values, too. >> >> On Sun, May 30, 2010 at 10:57 AM, Erick Erickson >> wrote: >> > Then you have to provide a lot more detail about what you did >> > and what you're seeing and what you think you should see. You >> > might review this page: >> > http://wiki.apache.org/solr/UsingMailingLists >> > >> > Best >> > Erick >> > >> > On Sun, May 30, 2010 at 1:41 PM, jlist9 wrote: >> > >> >> I find in the Plugins tab that the default is PersianAnalyzer. I >> switched >> >> to StandardAnalyzer and tried a few different Lucene Compatibility >> values >> >> but it didn't help :-( >> >> >> >> On Sun, May 30, 2010 at 4:40 AM, Erick Erickson < >> erickerick...@gmail.com> >> >> wrote: >> >> > The Solr admin page as access to (and uses) the field >> >> > definitions you've put in the config file. Luke has no >> >> > knowledge of this configuration, you have to choose >> >> > your analyzer from the drop down and select the one >> >> > closest to what's in your config file for SOLR. Are you >> >> > perhaps using an analyzer in Luke that doesn't >> >> > play nice with the definitions in SOLR? >> >> > >> >> > HTH >> >> > Erick >> >> > >> >> > >> >> > On Sat, May 29, 2010 at 10:55 PM, jlist9 wrote: >> >> > >> >> >> I tried the stand-alone Luke tool (not Luke request handler) to >> browse >> >> >> a solr index and find a few strange things: >> >> >> >> >> >> 1. Queries like "id:123" which work fine in /solr/admin web interface >> >> >> returns nothing in Luke. "*:*" returns everything fine in Luke. >> >> >> >> >> >> 2. When Luke displays records with query "*:*", it shows the string >> >> >> values fine but the numeric fields and date fields shows blank. It >> shows >> >> >> DocID OK, though. >> >> >> >> >> >> Anyone else has tried Luke on a solr index? >> >> >> >> >> > >> >> >> > >> >
Re: Luke browser does not show non-String Solr fields?
Thanks for the suggestion. I tried 0.9.9.1 but saw the same problem. I didn't see 0.9.9 on their download page. On Mon, May 31, 2010 at 2:39 AM, Ahmet Arslan wrote: > >> Solr 1.4 >> >> > You haven't identified the version of Luke you're >> using. >> >> Luke 1.0.1 (2010-04-01) >> > > I think with solr you need to use Release 0.9.9.1 or 0.9.9 > Because solr 1.4.0 uses lucene 2.9.1 > > > >
Re: Luke browser does not show non-String Solr fields?
The id field has type "long" in schema.xml. In Luke, they are shown as "hex dump". When viewing a doc (returned by *:*), I pick the ID field and press the "Show" button, Luke pops up a dialog that allows me to change the "Show Content As" value. When I choose "Number", I get an error message: "Some values could not be properly represented in this format. They are marked in grey and presented as a hex dump." So it seems like Luke does not understand Solr's long type. This is not a native Lucene type? On Mon, May 31, 2010 at 9:52 AM, Chris Hostetter wrote: > > : 1. Queries like "id:123" which work fine in /solr/admin web interface but > : returns nothing in Luke. Query "*:*" returns all records fine in Luke. I > : expect Luke returns the same result as /solr/admin since it's essentially > : a Lucene query? > > you haven't told us what fieldtype you are using for the "id" field -- but > i'm going to go out on a limb and guess it's TrieIntFieldType (or possibly > a SortedIntFieldType) ... those field types encode their values in such a > way that they sort lexigraphicaly and produce faster range queries -- if > Luke doesn't kow about that special encoding, it can search on them (or > even display the terms properly) > > Luke has a "view terms" feature right? ... look at the raw terms in your > "id" ifeld and i bet you'll see they look nothing like numbers -- and > that's why you can search on them as numbers in Luke > > (when you serach on them in Solr, SOlr knows about your schema, and knows > about your field types, and can do the proper encoding/decoding) > > > > -Hoss > >
MoreLikeThis: /solr/mlt NOT_FOUND
I have some experience using MLT with the StandardRequestHandler with Python but I can't figure out how to do it with solrj. It seems that to do MLT with solrj I have to use MoreLikeThisRequestHandler and there seems no way to use StandardRequestHandler for MLT with solrj (please correct me if I'm wrong.) So I try to test it by following this page: http://wiki.apache.org/solr/MoreLikeThisHandler but I get this error: HTTP ERROR: 404 NOT_FOUND RequestURI=/solr/mlt Do I need to do something in the config file before I can use MLT? Thanks
Re: MoreLikeThis: /solr/mlt NOT_FOUND
That's it. Thank you!
I thought mlt was available by default. I was wrong.
On Tue, Jun 1, 2010 at 8:22 AM, Ahmet Arslan wrote:
>> I have some experience using MLT with
>> the StandardRequestHandler with Python
>> but I can't figure out how to do it with solrj. It seems
>> that to do
>> MLT with solrj I have
>> to use MoreLikeThisRequestHandler and there seems no way to
>> use
>> StandardRequestHandler for MLT with solrj (please correct
>> me if I'm wrong.)
>>
>> So I try to test it by following this page:
>> http://wiki.apache.org/solr/MoreLikeThisHandler
>> but I get this error:
>>
>> HTTP ERROR: 404
>> NOT_FOUND
>> RequestURI=/solr/mlt
>>
>> Do I need to do something in the config file before I can
>> use MLT?
>
> Did you register /mlt in your solrconfig.xml?
>
> class="org.apache.solr.handler.MoreLikeThisHandler">
>
> list
>
>
>
> you can invoke it with SolrQuery.set("qt", "/mlt");
Re: Luke browser does not show non-String Solr fields?
I see. It's still a little confusing to me but I'm fine as long as this is the expected behavior. I also tried the "example" index with data that come with the solr distribution and observe the same behavior - only String fields are displayed. So Lucene is sharing _some_ types with Solr but not all. It's still a bit puzzling to me that Lucene is not able to understand the simple types such as long. But I'm OK as long as there is a reason. Thanks for the explanations! On Tue, Jun 1, 2010 at 10:38 AM, Chris Hostetter wrote: > > : So it seems like Luke does not understand Solr's long type. This > : is not a native Lucene type? > > No, Lucene has concept of "types" ... there are utilities to help encode > some data in special ways (particularly numbers) but the underlying lucene > index doesn't keep track of when/how you do ths -- so Luke has no way of > knowing what "type" the field is. > > Schema information is specific to Solr. > > > -Hoss > >
Re: Luke browser does not show non-String Solr fields?
Thank you Chris. I'm clear now. I'll give Luke's latest version a try when it's out. On Wed, Jun 2, 2010 at 9:47 AM, Chris Hostetter wrote: > > : I see. It's still a little confusing to me but I'm fine as long as > : this is the expected behavior. I also tried the "example" index > : with data that come with the solr distribution and observe the > : same behavior - only String fields are displayed. So Lucene is > : sharing _some_ types with Solr but not all. It's still a bit puzzling > : to me that Lucene is not able to understand the simple types > : such as long. But I'm OK as long as there is a reason. Thanks > : for the explanations! > > The key is that there are *no* types in Lucene ... older > versions of Lucene only supported "Strin" and clinets that wanted to index > other types had to encode those types in some way as needed. More > recently lucene has started moving away from even dealing with Strings, > and towards just indexing/searching raw byte[] ... all concepts of "field > types" in Solr are specific to Solr > > (the caveat being that Lucene has, over the years, added utilities to help > people make smart choices about how to encode some data types -- and in > the case of the Trie numeric fields SOlr uses those utilites. But that > data isn't stored anywhere in the index files themselves, so Luke has no > way of knowing that it should attempt to "decode" the binary data of a > field using the Trie utilities. That said: aparently Andrzej is working > on making it possible to tell Luke "oh BTW, i indexed this field using > this solr fieldType" ... i think he said it was on the Luke trunk) > > > -Hoss
solrj Unicode queries don't return results
Hi, I'm having a problem with Unicode queries using solrj. I have an index with unicode strings. From /solr/admin web interface, I can find results using the Java unicode format, such as \u751f\u6d3b. (If I just type in a UTF-8 string, I can't find any result though. Not sure why.) But in solrj, I tried having the string in UTF-8 in UTF-8 encoded Java source file, and I also tried using the Java unicode format in query.setQuery( ), but none of these approaches return any results. When I searched online, I found a similar question here w/o no answers. http://www.mail-archive.com/solr-user@lucene.apache.org/msg21380.html So what's the right way of doing unicode queries with solrj? Thank you, Jack
Re: solrj Unicode queries don't return results
Thank you for the reply! I'm using Tomcat 6.0.20. I read the page. I think you meant setting URIEncoding for the connector: I tried this but it still doesn't work, while the Python client still works fine. Because the Python client works fine, I tend to think that solrj is not encoding the URL properly, as opposed to Tomcat not decoding it correctly. Is there anything I should do to make solrj do the right thing? Meanwhile, I'd like to try using POST, but I didn't find information about how to do this. Could someone point me to a link to some sample code? On Mon, Jun 7, 2010 at 11:42 AM, Tim Gilbert wrote: > I had the same problem a while back. You didn't mention which > application server you are using (if any) but some application servers > have problems with UTF-8 queries and GET. > > Tomcat has a well documented solution > http://wiki.apache.org/solr/SolrTomcat (near the bottom), I recently > experienced problems with glassfish and switched to post to solve it > (http://wiki.apache.org/solr/SolrGlassfish) > > Tim > > -Original Message- > From: jlist9 [mailto:jli...@gmail.com] > Sent: Monday, June 07, 2010 2:33 PM > To: solr-user@lucene.apache.org > Cc: dioxide.softw...@gmail.com > Subject: solrj Unicode queries don't return results > > Hi, I'm having a problem with Unicode queries using solrj. > I have an index with unicode strings. From /solr/admin web interface, > I can find results using the Java unicode format, such as \u751f\u6d3b. > (If I just type in a UTF-8 string, I can't find any result though. Not > sure why.) > > But in solrj, I tried having the string in UTF-8 in UTF-8 encoded Java > source > file, and I also tried using the Java unicode format in query.setQuery( > ), > but none of these approaches return any results. > > When I searched online, I found a similar question here w/o no answers. > http://www.mail-archive.com/solr-user@lucene.apache.org/msg21380.html > > So what's the right way of doing unicode queries with solrj? > > Thank you, > Jack >
Re: solrj Unicode queries don't return results
I was using SolrQuery. Now I'm switching to QueryRequest. Hope this works. Thanks! On Mon, Jun 7, 2010 at 11:26 PM, jlist9 wrote: > Thank you for the reply! I'm using Tomcat 6.0.20. I read the page. > I think you meant setting URIEncoding for the connector: > > > I tried this but it still doesn't work, while the Python client still > works fine. > Because the Python client works fine, I tend to think that solrj is not > encoding the URL properly, as opposed to Tomcat not decoding it correctly. > Is there anything I should do to make solrj do the right thing? > > Meanwhile, I'd like to try using POST, but I didn't find information > about how to do this. Could someone point me to a link to some > sample code? > > On Mon, Jun 7, 2010 at 11:42 AM, Tim Gilbert > wrote: >> I had the same problem a while back. You didn't mention which >> application server you are using (if any) but some application servers >> have problems with UTF-8 queries and GET. >> >> Tomcat has a well documented solution >> http://wiki.apache.org/solr/SolrTomcat (near the bottom), I recently >> experienced problems with glassfish and switched to post to solve it >> (http://wiki.apache.org/solr/SolrGlassfish) >> >> Tim >> >> -Original Message- >> From: jlist9 [mailto:jli...@gmail.com] >> Sent: Monday, June 07, 2010 2:33 PM >> To: solr-user@lucene.apache.org >> Cc: dioxide.softw...@gmail.com >> Subject: solrj Unicode queries don't return results >> >> Hi, I'm having a problem with Unicode queries using solrj. >> I have an index with unicode strings. From /solr/admin web interface, >> I can find results using the Java unicode format, such as \u751f\u6d3b. >> (If I just type in a UTF-8 string, I can't find any result though. Not >> sure why.) >> >> But in solrj, I tried having the string in UTF-8 in UTF-8 encoded Java >> source >> file, and I also tried using the Java unicode format in query.setQuery( >> ), >> but none of these approaches return any results. >> >> When I searched online, I found a similar question here w/o no answers. >> http://www.mail-archive.com/solr-user@lucene.apache.org/msg21380.html >> >> So what's the right way of doing unicode queries with solrj? >> >> Thank you, >> Jack >> >
Re: solrj Unicode queries don't return results
Ah, I didn't know this. This should be much simpler. Thank you very much! On Tue, Jun 8, 2010 at 12:57 AM, Ahmet Arslan wrote: >> Meanwhile, I'd like to try using POST, but I didn't find >> information >> about how to do this. Could someone point me to a link to >> some >> sample code? > > > you can pass METHOD.POST to query method of SolrServer. > > public QueryResponse query(SolrParams params, METHOD method) > > > >
