Re: [VOTE] Community Logo Preferences
https://issues.apache.org/jira/secure/attachment/12394268/apache_solr_c_red.jpg https://issues.apache.org/jira/secure/attachment/12394350/solr.s4.jpg https://issues.apache.org/jira/secure/attachment/12394376/solr_sp.png https://issues.apache.org/jira/secure/attachment/12394267/apache_solr_c_blue.jpg -- Best regards, Andrzej Bialecki <>< ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com
RE: Deleting indices
Can anybody please let me know why is this happening? I have also tried giving indexed="false" for name field in the xml. -Original Message- From: Raghunandan Rao [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 6:18 PM To: solr-user@lucene.apache.org Subject: RE: Deleting indices I have restarted and re-indexed all the docs after the change in the schema.xml. I was able to search even after that. I hit browser with this url http://localhost:7001/solr/select?q=name:2124&fl=*&debugQuery=true -Original Message- From: Shalin Shekhar Mangar [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 6:14 PM To: solr-user@lucene.apache.org Subject: Re: Deleting indices Did you change your schema.xml after you indexed the documents? On Wed, Nov 26, 2008 at 6:08 PM, Raghunandan Rao < [EMAIL PROTECTED]> wrote: > I am not sure. It is showing in the debug logs as below. > > 0.5967079 = (MATCH) fieldWeight(name:2124 in 0), product of: 1.4142135 = > tf(termFreq(name:2124)=2) 1.1251632 = idf > > This is how I have done. > I have a class NameDTO which contains all these variables. I have @Field > annotation to these fields. My schema.xml file contains as I have said > below. Is that because I have @Field annotation it is indexing? > > -Original Message- > From: Shalin Shekhar Mangar [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 26, 2008 5:47 PM > To: solr-user@lucene.apache.org > Subject: Re: Deleting indices > > On Wed, Nov 26, 2008 at 5:01 PM, Raghunandan Rao < > [EMAIL PROTECTED]> wrote: > > > Ok. > > I have another query on search. > > > > I have given two fields to be indexed = true in xml. > > > > > > > required="false"/> > > > required="false"/> > > > > But when I try to search on non-indexed "name" field it is able to > retrieve > > records. How is this possible? > > > > It is not possible. There must be an indexed field which contained that > value. > > Execute your query from the web interface and add debugQuery=true to > your > search request to see details on how it is being searched. > -- > Regards, > Shalin Shekhar Mangar. > -- Regards, Shalin Shekhar Mangar.
Re: omiting no price documents when sorting on price
was hoping there was an option to omit results with a certain value to stop certain fields containing 0 skewing the search results. i will try not sending the field if its 0. cheers! joe joeMcElroy wrote: > > im sure this is an easy question but... > > when a product doesn't have a price, I index the price as 0. When sorting > on price, these values come up first or last. How can you omit these items > when sorting against price. > > thanks > > joe > -- View this message in context: http://www.nabble.com/omiting-no-price-documents-when-sorting-on-price-tp20703795p20716352.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: omiting no price documents when sorting on price
You can omit documents. I recommend doing it with a filter query. Append the following to your request to Solr: &fq=-price:0 That does the trick? You'll have to have client logic to only add that parameter when sorting by price, if that's how you want it to work. Erik On Nov 27, 2008, at 4:59 AM, joeMcElroy wrote: was hoping there was an option to omit results with a certain value to stop certain fields containing 0 skewing the search results. i will try not sending the field if its 0. cheers! joe joeMcElroy wrote: im sure this is an easy question but... when a product doesn't have a price, I index the price as 0. When sorting on price, these values come up first or last. How can you omit these items when sorting against price. thanks joe -- View this message in context: http://www.nabble.com/omiting-no-price-documents-when-sorting-on-price-tp20703795p20716352.html Sent from the Solr - User mailing list archive at Nabble.com.
RE: Keyword extraction
Hi Aleksander, With all the help of you and the other comments, we're now at a point where a MoreLikeThis list is returned, and shows 10 related records. However on the query executed there are no keywords whatsoever being returned. Is the querystring still wrong or is something else required? The querystring we're currently executing is: http://suempnr3:8080/solr/select/?q=amsterdam&mlt.fl=text&mlt.displayTerms=list&mlt=true Best, Patrick -Original Message- From: Aleksander M. Stensby [mailto:[EMAIL PROTECTED] Sent: woensdag 26 november 2008 15:07 To: solr-user@lucene.apache.org Subject: Re: Keyword extraction Ah, yes, That is important. In lucene, the MLT will see if the term vector is stored, and if it is not it will still be able to perform the querying, but in a much much much less efficient way.. Lucene will analyze the document (and the variable DEFAULT_MAX_NUM_TOKENS_PARSED will be used to limit the number of tokens that will be parsed). (don't want to go into details on this since I haven't really dug through the code:p) But when the field isn't stored either, it is rather difficult to re-analyze the document;) On a general note, if you want to "really" understand how the MLT works, take a look at the wiki or read this thorough blog post: http://cephas.net/blog/2008/03/30/how-morelikethis-works-in-lucene/ Regards, Aleksander On Wed, 26 Nov 2008 14:41:52 +0100, Plaatje, Patrick <[EMAIL PROTECTED]> wrote: > Hi Aleksander, > > This was a typo on my end, the original query included a semicolon > instead of an equal sign. But I think it has to do with my field not > being stored and not being identified as termVectors="true". I'm > recreating the index now, and see if this fixes the problem. > > Best, > > patrick > > -Original Message- > From: Aleksander M. Stensby [mailto:[EMAIL PROTECTED] > Sent: woensdag 26 november 2008 14:37 > To: solr-user@lucene.apache.org > Subject: Re: Keyword extraction > > Hi there! > Well, first of all i think you have an error in your query, if I'm not > mistaken. > You say http://localhost:8080/solr/select/?q=id=18477975... > but since you are referring to the field called "id", you must say: > http://localhost:8080/solr/select/?q=id:18477975... > (use colon instead of the equals sign). > I think that will do the trick. > If not, try adding the &debugQuery=on at the end of your request url, > to see debug output on how the query is parsed and if/how any > documents are matched against your query. > Hope this helps. > > Cheers, > Aleksander > > > > On Wed, 26 Nov 2008 13:08:30 +0100, Plaatje, Patrick > <[EMAIL PROTECTED]> wrote: > >> Hi Aleksander, >> >> Thanx for clearing this up. I am confident that this is a way to >> explore for me as I'm just starting to grasp the matter. Do you know >> why I'm not getting any results with the query posted earlier then? >> It gives me the folowing only: >> >> >> >> >> Instead of delivering details of the interestingTerms. >> >> Thanks in advance >> >> Patrick >> >> >> -Original Message- >> From: Aleksander M. Stensby [mailto:[EMAIL PROTECTED] >> Sent: woensdag 26 november 2008 13:03 >> To: solr-user@lucene.apache.org >> Subject: Re: Keyword extraction >> >> I do not agree with you at all. The concept of MoreLikeThis is based >> on the fundamental idea of TF-IDF weighting, and not term frequency >> alone. >> Please take a look at: >> http://lucene.apache.org/java/2_4_0/api/org/apache/lucene/search/simi >> l ar/MoreLikeThis.html As you can see, it is possible to use cut-off >> thresholds to significantly reduce the number of unimportant terms, >> and generate highly suitable queries based on the tf-idf frequency of >> the term, since as you point out, high frequency terms alone tends to >> be useless for querying, but taking the document frequency into >> account drastically increases the importance of the term! >> >> In solr, use parameters to manipulate your desired results: >> http://wiki.apache.org/solr/MoreLikeThis#head-6460069f297626f2a982f1e >> 2 >> 2ec5d1519c456b2c >> For instance: >> mlt.mintf - Minimum Term Frequency - the frequency below which terms >> will be ignored in the source doc. >> mlt.mindf - Minimum Document Frequency - the frequency at which words >> will be ignored which do not occur in at least this many docs. >> You can also set thresholds for term length etc. >> >> Hope this gives you a better idea of things. >> - Aleks >> >> On Wed, 26 Nov 2008 12:38:38 +0100, Scurtu Vitalie >> <[EMAIL PROTECTED]> >> wrote: >> >>> Dear Partick, I had the same problem with MoreLikeThis function. >>> >>> After briefly reading and analyzing the source code of moreLikeThis >>> function in solr, I conducted: >>> >>> MoreLikeThis uses term vectors to ranks all the terms from a >>> document by its frequency. According to its ranking, it will start >>> to generate queries, artificially, and search for documents. >>> >>> So, moreLikeThis will retrieve
Re: Keyword extraction
Hi again Patrick. Glad to hear that we can contribute to help you guys. Thats what this mailing list is for:) First of all, I think you use the wrong parameter to get your terms. Take a look at http://lucene.apache.org/solr/api/org/apache/solr/common/params/MoreLikeThisParams.html to see the supported params. In your string you use mlt.displayTerms=list, which i believe should be mlt.interestingTerms=list. If that doesn't work: One thing you should know is that from what i can tell, you are using the StandardRequestHandler in your querying. The StandardRequestHandler supports a simplified handling of more like these queries, namely; "This method returns similar documents for each document in the response set." it supports the common mlt parameters, needs mlt=true (as you have done) and supports a mlt.count parameter to specify the number of similar documents returned for each matching doc from your query. If you want to get the "top keywords" etc, (and in essence your mlt.interestingTerms=list parameter to have any effect at all, if I'm not completely wrong), you will need to configure up a MoreLikeThisHandler in your solrconfig.xml and then map that to your query. From the sample configuration file: incoming queries will be dispatched to the correct handler based on the path or the qt (query type) param. Names starting with a '/' are accessed with the a path equal to the registered name. Names without a leading '/' are accessed with: http://host/app/select?qt=name If no qt is defined, the requestHandler that declares default="true" will be used. You can read about the MoreLikeThisHandler here: http://wiki.apache.org/solr/MoreLikeThisHandler Once you have it configured properly your query would be something like: http://localhost:8983/solr/mlt?q=amsterdam&mlt.fl=text&mlt.interestingTerms=list&mlt=true (don't think you need the mlt=true here tho...) or http://localhost:8983/solr/select?qt=mlt&q=amsterdam&mlt.fl=text&mlt.interestingTerms=list&mlt=true (in the last example I use qt=mlt) Hope this helps. Regards, Aleksander On Thu, 27 Nov 2008 11:49:30 +0100, Plaatje, Patrick <[EMAIL PROTECTED]> wrote: Hi Aleksander, With all the help of you and the other comments, we're now at a point where a MoreLikeThis list is returned, and shows 10 related records. However on the query executed there are no keywords whatsoever being returned. Is the querystring still wrong or is something else required? The querystring we're currently executing is: http://suempnr3:8080/solr/select/?q=amsterdam&mlt.fl=text&mlt.displayTerms=list&mlt=true Best, Patrick -Original Message- From: Aleksander M. Stensby [mailto:[EMAIL PROTECTED] Sent: woensdag 26 november 2008 15:07 To: solr-user@lucene.apache.org Subject: Re: Keyword extraction Ah, yes, That is important. In lucene, the MLT will see if the term vector is stored, and if it is not it will still be able to perform the querying, but in a much much much less efficient way.. Lucene will analyze the document (and the variable DEFAULT_MAX_NUM_TOKENS_PARSED will be used to limit the number of tokens that will be parsed). (don't want to go into details on this since I haven't really dug through the code:p) But when the field isn't stored either, it is rather difficult to re-analyze the document;) On a general note, if you want to "really" understand how the MLT works, take a look at the wiki or read this thorough blog post: http://cephas.net/blog/2008/03/30/how-morelikethis-works-in-lucene/ Regards, Aleksander On Wed, 26 Nov 2008 14:41:52 +0100, Plaatje, Patrick <[EMAIL PROTECTED]> wrote: Hi Aleksander, This was a typo on my end, the original query included a semicolon instead of an equal sign. But I think it has to do with my field not being stored and not being identified as termVectors="true". I'm recreating the index now, and see if this fixes the problem. Best, patrick -Original Message- From: Aleksander M. Stensby [mailto:[EMAIL PROTECTED] Sent: woensdag 26 november 2008 14:37 To: solr-user@lucene.apache.org Subject: Re: Keyword extraction Hi there! Well, first of all i think you have an error in your query, if I'm not mistaken. You say http://localhost:8080/solr/select/?q=id=18477975... but since you are referring to the field called "id", you must say: http://localhost:8080/solr/select/?q=id:18477975... (use colon instead of the equals sign). I think that will do the trick. If not, try adding the &debugQuery=on at the end of your request url, to see debug output on how the query is parsed and if/how any documents are matched against your query. Hope this helps. Cheers, Aleksander On Wed, 26 Nov 2008 13:08:30 +0100, Plaatje, Patrick <[EMAIL PROTECTED]> wrote: Hi Aleksander, Thanx for clearing this up. I am confident that this is a way to explore for me as I'm just starting to grasp the matter. Do you know why I'm not getting any results with the quer
SolrException: HTTP code=503
Hello all, I'm having this issue bellow .. can some one tell me what I have to change in the config file to overcome this issue ? SolrException: HTTP code=503, reason=Error opening new searcher. exceeded limit of maxWarmingSearchers=4, try again later. thanks a lot Ak _ See the most popular videos on the web http://clk.atdmt.com/GBL/go/115454061/direct/01/
Re: range queries on string field with millions of values
I did not even understand what you are considering to be the order on your call numbers. 2008/11/26 Naomi Dushay <[EMAIL PROTECTED]> > I have a performance problem and I haven't thought of a clever way around > it. > > I work at the Stanford University Libraries. We have a collection of over > 8 million items. Each item has a call number. I have been asked to provide > a way to browse forward and backward from an arbitrary call number. > > I have managed to create a fields that present the call numbers in > appropriate sorts, both forward and reverse. (This is necessary because raw > call numbers don't sort properly: A123 AZ27 B99 B999 BBB11). > > We can ignore the reverse sorted range query problem; it's the same as the > forward sorted range query. > > So I use a query like this: > > sortCallNum["A123 B34 1970" TO *]&rows=10. > > > Call numbers are squirrelly, so we can't predict the string that will > appropriately grab at least 10 subsequent documents. They are certainly not > consecutive! > > so from > A123 B34 1970 > > we're unable to predict if any of these will return at least 10 results: > > A123 B34 1980 or > A123 B34 V.8 or > A123 B44 or > A123 B67 or > A123 C27 or > A124* or > A22* or > AA* or > > You get the idea. > > I have not figured out a way to efficiently query for "the next 10 call > numbers in sort order". I have also mucked about with the cache > initialization, but that's not working either: > > > > > >shelfkey:[0 TO *] >shelfkey asc > > > > Can anyone help me with this? > > - Naomi > > -- Alexander Ramos Jardim
Re: facet.sort and distributed search
Hi, Thanks a lot for your answer : I've tried the patch and it works fine. regards, 2008/11/27 Aleksander M. Stensby <[EMAIL PROTECTED]>: > This is a known issue but take a look at the following jira issue and the > patch supplied there: > https://issues.apache.org/jira/browse/SOLR-764 > > Haven't tried it myself, but i believe it should do the trick for you. > Hope that helps. > > Cheers, > Aleksander > > On Wed, 26 Nov 2008 22:53:21 +0100, Grégoire Neuville > <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> I'm working on an web application one functionality of which consists >> in presenting to the user a list of terms to seize in a form field, >> sorted alphabetically. As long as one single index was concerned, I >> used solr facets to produce the list and it worked fine. But I must >> now deal with several indices, and thus use the distributed search >> capability of solr, which forbid the use of "facet.sort=false". >> >> I would like to know if someone plans to, or is even working on, the >> implementation of the natural facet sorting in case of a distributed >> search. >> >> Thanks a lot, > > > > -- > Aleksander M. Stensby > Senior software developer > Integrasco A/S > www.integrasco.no > -- Grégoire Neuville
Re: Deleting indices
On 26-Nov-08, at 4:48 AM, Raghunandan Rao wrote: I have restarted and re-indexed all the docs after the change in the schema.xml. I was able to search even after that. I hit browser with this url http://localhost:7001/solr/select?q=name:2124&fl=*&debugQuery=true Are you sure all the old docs are gone? Try wiping the index completely: deleteByQuery *:* (it is also more efficient to do this first if you are going to re- index everything). -Mike
Mock solr server
Hi, Does anyone know of an easy to use Mock solr server? Thanks Rob
Re: Mock solr server
are you trying to unit test something? I would simply make use of the Embedded SOLR component in your unit tests.. On 11/27/08, Robert Young <[EMAIL PROTECTED]> wrote: > Hi, > > Does anyone know of an easy to use Mock solr server? > > Thanks > Rob > -- Jeryl Cook /^\ Pharaoh /^\ http://pharaohofkush.blogspot.com/ "Whether we bring our enemies to justice, or bring justice to our enemies, justice will be done." --George W. Bush, Address to a Joint Session of Congress and the American People, September 20, 2001
RE: Deleting indices
Yes, I am sure. Everytime I re-index, I do deleteByQuery("*:*") and then
fetch the rows from DB and call server.addBeans(list).
-Original Message-
From: Mike Klaas [mailto:[EMAIL PROTECTED]
Sent: Friday, November 28, 2008 4:30 AM
To: solr-user@lucene.apache.org
Subject: Re: Deleting indices
On 26-Nov-08, at 4:48 AM, Raghunandan Rao wrote:
> I have restarted and re-indexed all the docs after the change in the
> schema.xml. I was able to search even after that.
>
> I hit browser with this url
>
> http://localhost:7001/solr/select?q=name:2124&fl=*&debugQuery=true
Are you sure all the old docs are gone? Try wiping the index
completely:
deleteByQuery *:*
(it is also more efficient to do this first if you are going to re-
index everything).
-Mike
Re: [VOTE] Community Logo Preferences
https://issues.apache.org/jira/secure/attachment/12394268/apache_solr_c_red.jpg https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png https://issues.apache.org/jira/secure/attachment/12394267/apache_solr_c_blue.jpg regards, shrutipriya
