On 3/11/2015 4:28 PM, Shawn Heisey wrote:
> When I have some time to actually work on the code, I'm going to write
> it using 4.x classes because that's what I have immediate access to,
> but if you do 5.x, SolrServer becomes SolrClient, and HttpSolrServer
> becomes HttpSolrClient.

At the URL below is the code I came up with.  It shows how to do an add,
a commit, and a query where the Solr core (collection) is specified as
part of the request, rather than the server connection:

http://apaste.info/lRi

I did test this code successfully, although there was one difference in
that code (/update instead of /update/javabin) because my dev Solr
server is running 4.9.1, not 3.5.  The code I've shared uses SolrJ 4.x,
but is tailored to a server running 3.x with a typical 3.x config.  I
hope this code will work as-is ... and if it doesn't, that it will be
easy for you to figure out what I did wrong.

If you want to figure out how to use SolrRequest to implement a query
with a specific handler path, you could probably implement all of this
in SolrJ 3.5, where SolrQuery#setRequestHandler does not exist.  I'm
sure that if you look at the SolrQuery class and the
CommonsHttpSolrServer#query method from the 3.5 source code, you could
piece together how to do this.

It might be a good idea to abstract these procedures for add, commit,
and query into your own local methods that include the collection
parameter.  If you need it, you can also implement
UpdateRequest.ACTION.OPTIMIZE in a similar manner to the way that I used
UpdateRequest.ACTION.COMMIT.

See the following issue for the recent work that will go into a new 5.x
version (probably 5.1), which adds the capability you are seeking
directly to HttpSolrClient, implementing abstract methods from SolrClient:

https://issues.apache.org/jira/browse/SOLR-7201


Thanks,
Shawn

Reply via email to