[jira] Resolved: (SOLR-46) support for appended and invariant SolrParams in solrconfig.xml
[ http://issues.apache.org/jira/browse/SOLR-46?page=all ] Hoss Man resolved SOLR-46. -- Resolution: Fixed commited with some spell corrections in examplesolrconfig.xml > support for appended and invariant SolrParams in solrconfig.xml > --- > > Key: SOLR-46 > URL: http://issues.apache.org/jira/browse/SOLR-46 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Hoss Man > Assigned To: Hoss Man > Attachments: appends-and-invariants.patch > > > this patch would add support to StandardRequestHandler and > DisMaxRequestHandler for specifying "appends" and "invariants" SolrParams in > the solrconfig.xml, from the example config... > In addition to defaults, "appends" params can be specified > to identify values which whould be appended to the list of > multi-valu params from the query (or the existing "defaults"). > ... > "invariants" are a way of letting the Solr maintainer lock down > the options available to Solr clients. Any params values > specified here are used regardless of what values may be specified > in either the query, the "defaults", or the "appends" params. > ...functionality is largely reusable by any handler, via > SolrPluginUtils.setDefaults. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: automatic facet.limit?
On 9/12/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: as long as there is a way to trigger the unbounded behavior (with limit=0 or limit=-1) having a "sensible" upper bound by default makes sense. A limit of 0 can make sense, so mapping -1 to unbounded seems like a better choice. -Yonik
Re: custom update handler questions
On 9/12/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: What are the pros/cons to having a custom update handler that can accept just a unique id and data for specific fields of a document, such that all the fields from the existing document are picked up on the Solr side and updated with the ones sent by the client? First, update handlers aren't at the same level as query handlers. Things were designed for custom query handlers, but aren't really designed for custom update handlers... that's tricky stuff. I'd like to rearrange the document design I'm using such that documents with large full-text fields can have certain small fields updated without having to send all the full-text across the wire. Of course all fields would be stored to facilitate this. Is this a big difficult deal, or reasonably implementable? You could implement your own update handler and delegate to DirectUpdateHandler2 for the work, but that has some difficulties if you want high update rates. The main problem being, what reader do you get the original stored fields from? If it's not a new reader, you might be going back in time and grabbing old fields because the doc was already updated. So for good performance you would need to: - check the pending set to see if that doc has been updated, and if so, open a new reader OR - Keep a reader open and buffer all your adds (this is the reverse logic that DirectUpdateHandler2 employs by buffering deletes). -Yonik
Re: Solr on Lucene home page?
: Yonik Seeley wrote: : > I recall sending a patch for this a month or two ago to the PMC :-) : : Now that you're on the PMC, you can reply to it! While you're at it, feel free to cut/past my ApacheCon blurb from the Solr "News" section into the Lucene news section (I didn't submit it as a patch before because Solr wasn't mentioned on the page at all -- but if it's fair game...) -Hoss
Re: automatic facet.limit?
: > Should we do the same for facet fields? But that means we might need : > a number to specify "no limit" (like 0 or -1). : : +1. Solr should make some effort to behave reasonably unless : explicitly directed otherwise. I suppose we should ... i avoided having a built in limit initially because there is added work neccessary to limit the results (managing the BoundedPriorityQuery) that i didn't want t do unless neccessary -- but you guys are right, as long as there is a way to trigger the unbounded behavior (with limit=0 or limit=-1) having a "sensible" upper bound by default makes sense. I'll take care of it. -Hoss
Re: Solr on Lucene home page?
Yonik Seeley wrote: I recall sending a patch for this a month or two ago to the PMC :-) Now that you're on the PMC, you can reply to it! Doug
custom update handler questions
What are the pros/cons to having a custom update handler that can accept just a unique id and data for specific fields of a document, such that all the fields from the existing document are picked up on the Solr side and updated with the ones sent by the client? I'd like to rearrange the document design I'm using such that documents with large full-text fields can have certain small fields updated without having to send all the full-text across the wire. Of course all fields would be stored to facilitate this. Is this a big difficult deal, or reasonably implementable? Thanks, Erik
Re: automatic facet.limit?
On 9/12/06, Yonik Seeley <[EMAIL PROTECTED]> wrote: I put in a built-in default limit of 10 returned docs for just this reason... to prevent people from shooting themselves in the foot when learning/fooling around with Solr. A person new to Solr might not even realize *why* firefox just hung on them when they tried the faceting feature. Should we do the same for facet fields? But that means we might need a number to specify "no limit" (like 0 or -1). +1. Solr should make some effort to behave reasonably unless explicitly directed otherwise. -Mike
automatic facet.limit?
I was just testing the new faceted browsing with a large dataset (25M records) and did facet=true&facet.field=author *boom*... firefox hangs hard after getting back megabytes and megabytes of XML, and the appserver heap isn't too happy. I put in a built-in default limit of 10 returned docs for just this reason... to prevent people from shooting themselves in the foot when learning/fooling around with Solr. A person new to Solr might not even realize *why* firefox just hung on them when they tried the faceting feature. Should we do the same for facet fields? But that means we might need a number to specify "no limit" (like 0 or -1). -Yonik
Re: [jira] Commented: (SOLR-30) Java client code for performing searches against a Solr instance
On 9/12/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: this is one of those situations where RequestHandlers deviat -- the StandardRequestHandler expects any sort to be specified with a ; after the query string -- the DisMaxRequestHandler uses a seperate paramater Perhaps we should add support for the sort param to the standard request handler. -Yonik
Re: Solr on Lucene home page?
On 9/12/06, Doug Cutting <[EMAIL PROTECTED]> wrote: Should Solr have a tab on Lucene's home page? Other incubating Lucene-related projects do. I think it would be appropriate. +1 I recall sending a patch for this a month or two ago to the PMC :-) -Yonik
Re: Solr on Lucene home page?
+1. Yoav On 9/12/06, Bill Au <[EMAIL PROTECTED]> wrote: +1 Bill On 9/12/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > > : Should Solr have a tab on Lucene's home page? Other incubating > : Lucene-related projects do. I think it would be appropriate. > > Oh yeah ... I forgot Lucene4c is in incubation too. > > +1, i'm all in favorof more solr visibility. > > > > -Hoss > >
Re: Solr on Lucene home page?
+1 Bill On 9/12/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: : Should Solr have a tab on Lucene's home page? Other incubating : Lucene-related projects do. I think it would be appropriate. Oh yeah ... I forgot Lucene4c is in incubation too. +1, i'm all in favorof more solr visibility. -Hoss
Re: Solr on Lucene home page?
: Should Solr have a tab on Lucene's home page? Other incubating : Lucene-related projects do. I think it would be appropriate. Oh yeah ... I forgot Lucene4c is in incubation too. +1, i'm all in favorof more solr visibility. -Hoss
Re: [jira] Commented: (SOLR-30) Java client code for performing searches against a Solr instance
: We did notice on thing that appears incorrect. The sort mechanism being : performed by the client adds a request parameter before sending to : lucene. : : /solr/select?q=term&sort=name+asc ... : According to lucene docs : (http://incubator.apache.org/solr/tutorial.html#Sorting), the sort : '''should be''' appended after the query term: : : /solr/select?q=term;name+asc this is one of those situations where RequestHandlers deviat -- the StandardRequestHandler expects any sort to be specified with a ; after the query string -- the DisMaxRequestHandler uses a seperate paramater -- a quick grep of the code from SOLR-30 seems to indicate that functionality is exposed in that API as "_dismaxSort" so the usage seems appropraite. this is one of the hard things to get right about a client API for Solr -- the request handler plugin approach makes the scope of legal requests almost as large as the scope of legal HTTP requests -- so designing an API that is general enough to use with more then one request handler, but still adds value beyond just using an HTTP client library directly is a delicate blanace. -Hoss
Re: Solr on Lucene home page?
+1 On 9/12/06, Doug Cutting <[EMAIL PROTECTED]> wrote: Should Solr have a tab on Lucene's home page? Other incubating Lucene-related projects do. I think it would be appropriate. Doug
Solr on Lucene home page?
Should Solr have a tab on Lucene's home page? Other incubating Lucene-related projects do. I think it would be appropriate. Doug
[jira] Commented: (SOLR-30) Java client code for performing searches against a Solr instance
[ http://issues.apache.org/jira/browse/SOLR-30?page=comments#action_12434202 ] John Hodgson commented on SOLR-30: -- Hi Phil. I'm using your search client and it is working pretty well. We did notice on thing that appears incorrect. The sort mechanism being performed by the client adds a request parameter before sending to lucene. /solr/select?q=term&sort=name+asc GET /solr/select?q=p*+AND+entryType%3Atag&sort=name+asc&rows=100 According to lucene docs (http://incubator.apache.org/solr/tutorial.html#Sorting), the sort '''should be''' appended after the query term: /solr/select?q=term;name+asc GET /solr/select?q=p*+AND+entryType%3Atag%3Bname+asc&rows=100 > Java client code for performing searches against a Solr instance > > > Key: SOLR-30 > URL: http://issues.apache.org/jira/browse/SOLR-30 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Philip Jacob >Priority: Minor > Attachments: solrsearcher-client.zip > > > Here are a few classes that connect to a Solr instance to perform searches. > Results are returned in a Response object. The Response encapsulates a > List> that gives you access to the key data in the results. > This is the main part that I'm looking for comments on. > There are 2 dependencies for this code: JDOM and Commons HttpClient. I'll > remove the JDOM dependency in favor of regular DOM at some point, but I think > that the HttpClient dependency is worthwhile here. There's a lot that can be > exploited with HttpClient that isn't demonstrated in this class. The purpose > here is mainly to get feedback on the API of SolrSearcher before I start > optimizing anything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
