You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "John Hodgson (JIRA)" <ji...@apache.org> on 2006/09/12 18:17:24 UTC
[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<Map<String,Field>> 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
Re: [jira] Commented: (SOLR-30) Java client code for performing
searches against a Solr instance
Posted by Chris Hostetter <ho...@fucit.org>.
: Perhaps we should add support for the sort param to the standard
: request handler.
+1
-Hoss
Re: [jira] Commented: (SOLR-30) Java client code for performing searches against a Solr instance
Posted by Yonik Seeley <yo...@apache.org>.
On 9/12/06, Chris Hostetter <ho...@fucit.org> 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: [jira] Commented: (SOLR-30) Java client code for performing
searches against a Solr instance
Posted by Chris Hostetter <ho...@fucit.org>.
: 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