Not able to get the meaning of first class support here. An example would be very helpful to clarify.

The current way of accessing the Real Time Get in SolrJ you need to do something along the lines of:

SolrDocument doc = solrServer.query(params("qt", "/get", "id", id)).getResponse().get("doc");

It would be convenient to provide a native method of (or similar variant):

SolrDocument doc = solrServer.get(id);

Just wondering should we also support POST and PUT as well like solrServer.post(id,object)

Just wondering should we also support POST and PUT as well like solrServer.post(id,object)

That's already supported by setting the method on the SolrRequest object. For example:

UpdateRequest updateRequest = new UpdateRequest();
updateRequest.setMethod(SolrRequest.METHOD.POST);

This issue is really providing yet another convenience method to perform CRUD operations.

Create & Update Operations:

UpdateResponse resp = solrServer.add(SolrInputDocument);
UpdateResponse resp = solrServer.add(Collection<SolrInputDocument>);
//+ a couple variants

These methods don't necessarily need to align to the various REST HTTP method semantics. The "add" action will perform a create or update clobbering the document already in place with the ability to perform an atomic update operation which will perform a merge with the document already in the index.

Delete Operations:

UpdateResponse resp = solrServer.deleteById(String id);
UpdateResponse resp = solrServer.deleteById(Collection<String> id);
UpdateResponse resp = solrServer.deleteByQuery(String query);
//+ a couple variants

Read Operations:

QueryResponse resp = solrServer.query(SolrParams);
//+ a couple variants

As you can see the delete operation allows you to delete given a specific id or delete by a query, whereas the retrieval only gives you query access. To be consistent this ticket should provide the ability to retrieve by id as a convenience to developers using the SolrJ API (not to mention the additional benefits they will get from the RealTimeGetHandler).

Implemented direct call to get the doc(s) by ID(s). Provided two apis

1. Takes 1 or more Ids using java variable number of args

 
GetByIdResponse getById(String... ids)

2. Takes input as set collection

GetByIdResponse getById(Set<String> ids)

Unit tests added for single(using #1) and multiple(using #1 & #2) ID(s) request(s).

Provided a simpler patch that doesn't create new GetByIdResponse & GetByIdRequest classes. Also, added the ability to specify your own custom SolrParams (useful for specifying fields & cores in SolrCloud):

SolrDocument getById(String id)
SolrDocument getById(String id, SolrParams params)
SolrDocumentList getById(Collection<String> ids)
SolrDocumentList getById(Collection<String> ids, SolrParams params)

Great job!

Commit 1654420 from shalin@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1654420 ]

SOLR-6449: Add first class support for Real Time Get in Solrj

Commit 1654422 from shalin@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1654422 ]

SOLR-6449: Add first class support for Real Time Get in Solrj

Thanks Anurag and Steve.

Steve, I changed your patch to not rely on common-collections because solrj does not depend on common-collections.

Cool, thanks Shalin. Just a side note, we could optimize retrievals a little for the Cloud client since it would have knowledge of which shard to route the traffic to (similar to how doc updates are handled) - perhaps a new follow-up ticket is in order just to let people know we thought about it .

Bulk close after 5.1 release