Re: Core not reloading in Solr 1.3
On Sat, Jul 25, 2009 at 8:46 AM, Ranjit Raveendran < contact_ranjit_...@yahoo.com> wrote: > Hi, > > I had emailed before about the following issue but did not get a response. > > I have been trying to reload the Solr core after I make changes to the > synonyms.txt file. With Solr 1.3, I am able to do a reload only after the > first change but not in subsequent attempts (after subsequent changes to > synonyms.txt). The reloads work fine with Solr nightly builds though (i.e. > I query using synonyms & get the desired results). > > I was wondering if someone could throw some light to this issue. I also > tried running Solr 1.3 throught Tomcat 6 but I see the same issue. > I see that you are using synonyms at index time therefore, changes to the synonym file cannot affect the documents which are already indexed. Although the changes to the synonym files are picked up after a core reload, documents which were indexed with the previous version of the synonym file will not have the new tokens and hence will not match. -- Regards, Shalin Shekhar Mangar.
Boolean query with 50,000 clauses! Possible? Scalable?
I am faced with the requirement for a boolean query composed of 50,000 clauses (all of them directed at the same field) all OR'ed together. I know that maxClauseCount can be set arbitrarily, but I am wondering whether this kind of query would chock and how scalable are this kind of queries (time/memory). Thank you in advance for your help and consideration -- View this message in context: http://www.nabble.com/Boolean-query-with-50%2C000-clauses%21-Possible--Scalable--tp24664831p24664831.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Facet sorting by boost functions
intresting. will that patch work in 1.4? On Sun, Jul 26, 2009 at 9:56 AM, Shalin Shekhar Mangar wrote: > On Sun, Jul 26, 2009 at 3:51 AM, Michael Lugassy wrote: > >> I'm using something along ?q=_val_:"product(field1,0.5)" and was >> wondering whether I could facet with category_id so that I get the >> single best document (product) for each category_id (not intrested in >> more than 5 of the best products in each of the highest-boosted >> category). >> > > I don't think there is a way to do that in one query right now. However, > this sounds like Field Collapsing: > > https://issues.apache.org/jira/browse/SOLR-236 > > -- > Regards, > Shalin Shekhar Mangar. > -- Sent from my mobile
Re: Core not reloading in Solr 1.3
Hi Shalin, Thank you for the reply. I do re-index the documents after a reload (which, in turn is done after I change the synonyms file) before submitting any queries. I.e. I do the following: a) change the synonyms file. b) reload the index (this *does not work in Solr 1.3* but works file in nightly builds) Lookin c) do a full import. d) submit queries. I do all the above in order & I re-submit queries using the new synonyms I had added, but I do need see any results. This is problem for only Solr 1.3 & not the nightly build. The above sequence works perfectly with the latter. Essentially, I following the steps outlined by Chris Hostetter in: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200906.mbox/%3c24185690.p...@talk.nabble.com%3e But his steps use the *trunk Solr code (nightly builds)* & *not* Solr 1.3. This seems like a bug to me but I'd like to confirm. Please let me know what you think. Looking forward to you reply. Thank you, Ranjit. --- On Sun, 7/26/09, Shalin Shekhar Mangar wrote: From: Shalin Shekhar Mangar Subject: Re: Core not reloading in Solr 1.3 To: solr-user@lucene.apache.org Date: Sunday, July 26, 2009, 3:00 AM On Sat, Jul 25, 2009 at 8:46 AM, Ranjit Raveendran < contact_ranjit_...@yahoo.com> wrote: > Hi, > > I had emailed before about the following issue but did not get a response. > > I have been trying to reload the Solr core after I make changes to the > synonyms.txt file. With Solr 1.3, I am able to do a reload only after the > first change but not in subsequent attempts (after subsequent changes to > synonyms.txt). The reloads work fine with Solr nightly builds though (i.e. > I query using synonyms & get the desired results). > > I was wondering if someone could throw some light to this issue. I also > tried running Solr 1.3 throught Tomcat 6 but I see the same issue. > I see that you are using synonyms at index time therefore, changes to the synonym file cannot affect the documents which are already indexed. Although the changes to the synonym files are picked up after a core reload, documents which were indexed with the previous version of the synonym file will not have the new tokens and hence will not match. -- Regards, Shalin Shekhar Mangar.
Re: tika 0.4?
I did test it, one unit test currently fails. On Jul 24, 2009, at 9:34 PM, Yonik Seeley wrote: On Fri, Jul 24, 2009 at 9:16 PM, Peter Wolanin> wrote: Sadly, I had to muis the meetup in NYC, but looking over the slides (http://files.meetup.com/1482573/YonikSeeley_NYCMeetup_solr14_features.pdf ) I see: Solr Cell: Integrates Apache Tika (v0.4) into Solr My current checkout of solr still has tika 0.3, and I don't see a jira issue for updating to 0.4. Is this something that's going to be in Solr 1.4 for sure? 99% sure. I jumped the gun a little bit... when I was prepping my slides, I saw on the Tika mailing list that Grant was going to handle the update to 0.4 (and had done most the work already - mostly a test adjustment to a metadata change I think). -Yonik http://www.lucidimagination.com
Re: Help needed with Solr
: You are correct, it's not a Solr issue, its due to HTTP GET is not being : able to send such a large request. : : But now the question is, Solr only accepts request in url form not as : request parameter or request object. That's the main issue. Hence we : need to send the query in url form only. There's a couple of of missleading statements and confusion above that i want to clarify for anyone reading... 1) there is no limit to how long a GET string can be in HTTP, there are only limits imposed by server/client implementatations, if your servlet container and your client support infinitely long URLs, Solr will work fine. 2) you can absolutely POST queries to Solr if you set the content type appropriately. furthermore: if you are sending queries that large, you should seriously consider refactoring your problem and thinking about why the queries are so large, and wether you can put some of the functionality that generates those large queries into a Solr plugin so you don't need to send so much data over the wire. -Hoss
Re: End-user documentation
: Subject: End-user documentation : References: <85d3c3b60907191934p4c0e63ceuf2712a17cea52...@mail.gmail.com> : In-Reply-To: <85d3c3b60907191934p4c0e63ceuf2712a17cea52...@mail.gmail.com> http://people.apache.org/~hossman/#threadhijack Thread Hijacking on Mailing Lists When starting a new discussion on a mailing list, please do not reply to an existing message, instead start a fresh email. Even if you change the subject line of your email, other mail headers still track which thread you replied to and your question is "hidden" in that thread and gets less attention. It makes following discussions in the mailing list archives particularly difficult. See Also: http://en.wikipedia.org/wiki/Thread_hijacking -Hoss
Re: Guide to using SolrQuery object
: It seems that SolrQuery is a better API than the basic ModifiableSolrParams,
: but I can't make it work.
can you elaborate a bit more on what it is you are tyring to do? ... ie:
show more of hte unit test you are writing ... what exactly are you doing
with the SolrQuery and/or ModifiableSolrParams objects once you construct
them?
SolrQuery is a SolrJ API object for executing queries against either a
remote or embedded instance of Solr; SolrParams is an API used internally
in Solr when executing requests -- very different purposes.
: Constructing params with:
: final ModifiableSolrParams params = new ModifiableSolrParams();
: params.set("q", queryString);
:
: ...results in a successful search.
:
: Constructing SolrQuery with:
: final SolrQuery solrQuery = new SolrQuery();
: solrQuery.setQuery(queryString);
:
: ... doesn't (with the same unit test driving the search). I'm sure I'm
: missing some basic option, but the javadoc is a little terse, and I don't
: see what I'm missing. Ideas?
:
: Also, are there enums or constants around the various param names that can
: be passed in, or do people tend to define those themselves?
:
: Thanks!
: Reuben
:
-Hoss
restart server necessary when changing schema+config?
it is not explicitly mentioned in solr documentation but I guess when changing stuff inside conf/ folder a restart of webserver is necessary? Or is there a reload URL call available? -- manuel aldana ald...@gmx.de software-engineering blog: http://www.aldana-online.de
Re: restart server necessary when changing schema+config?
On Jul 26, 2009, at 3:53 PM, manuel aldana wrote: it is not explicitly mentioned in solr documentation but I guess when changing stuff inside conf/ folder a restart of webserver is necessary? Or is there a reload URL call available? In single core, a restart of Solr is required to pick up changes to most* configuration files. In multi-core, cores can be reloaded through an HTTP command, however I believe searches will be unavailable during that core startup which can be a significant amount of time (minutes or so, most I've seen with heavy warming query scenarios). * DataImportHandler can reload its configuration files with an HTTP command. And some other files can be picked up dynamically (like VelocityResponseWriter templates). Erik
Re: Facet sorting by boost functions
apparently it does. what a great contriibution! got it to work with 1.4-dev. hopefully it will get into the stable release. On Sun, Jul 26, 2009 at 4:39 PM, Michael Lugassy wrote: > intresting. will that patch work in 1.4? > > On Sun, Jul 26, 2009 at 9:56 AM, Shalin Shekhar > Mangar wrote: >> On Sun, Jul 26, 2009 at 3:51 AM, Michael Lugassy wrote: >> >>> I'm using something along ?q=_val_:"product(field1,0.5)" and was >>> wondering whether I could facet with category_id so that I get the >>> single best document (product) for each category_id (not intrested in >>> more than 5 of the best products in each of the highest-boosted >>> category). >>> >> >> I don't think there is a way to do that in one query right now. However, >> this sounds like Field Collapsing: >> >> https://issues.apache.org/jira/browse/SOLR-236 >> >> -- >> Regards, >> Shalin Shekhar Mangar. >> > > > > -- > Sent from my mobile > -- Sent from my mobile
problems with + operator (seem to be treated as normal char and not as operator)
hi, I am having queries: +a b a b I always wondered why the + operator did not work. Looking at the http://localhost:8983/solr/admin/analysis.jsp analysis trace the query analzyer indeed is removing the + through the WordDelemiterFilterFactory. So I removed this filter (btw: why is this the default setting, which I think is a bit dangerous because the special + - operators are thus removed). Still '+a b' matches documents which have no 'a' inside the field. Now I guess solr is handling the '+' as a normal match character and not as an lucene (required) operator at all? Is this correct. If so, why is this lucene operator overridden? Maybe I need to escape the + for solr, so it treats it as an operator? thanks. -- manuel aldana ald...@gmx.de software-engineering blog: http://www.aldana-online.de
Re: problems with + operator (seem to be treated as normal char and not as operator)
manuel aldana wrote: hi, I am having queries: +a b a b I always wondered why the + operator did not work. Looking at the http://localhost:8983/solr/admin/analysis.jsp analysis trace the query analzyer indeed is removing the + through the WordDelemiterFilterFactory. So I removed this filter (btw: why is this the default setting, which I think is a bit dangerous because the special + - operators are thus removed). To debug quert parser, use FULL INTERFACE admin form (http://localhost:8983/solr/admin/form.jsp) and check Debug: enable and see debug info. You cannot use analysis.jsp for this purpose because it doesn't use query parser. Still '+a b' matches documents which have no 'a' inside the field. Now I guess solr is handling the '+' as a normal match character and not as an lucene (required) operator at all? Is this correct. If so, why is this lucene operator overridden? Maybe I need to escape the + for solr, so it treats it as an operator? thanks. Solr should use lucene query parser as long as you never explicitly use query parser other than lucene through defType, localParams, etc... I'm just guessing 'a' was filtered out by StopFilter? With example schema.xml, you can see: http://localhost:8983/solr/select?q=%2Ba+b&debugQuery=on +a b +a b text:b text:b http://localhost:8983/solr/select?q=cat%3A(%2Ba+b)&debugQuery=on cat:(+a b) cat:(+a b) +cat:a cat:b +cat:a cat:b Koji
