[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-20:
-------------------------
Summary: A simple Java client for updating and searching (was: A simple
Java client with Java APIs for add(), delete(), commit() and optimize().)
(NOTE: revised summary since this issue has moved beyond just updating)
I *finally* had a chance to look this over, here's a few comments in
no particular order...
1) i like the name solrj, i think this code should definitely live in
client/java/solrj so that there is the potential for other java client code
that is independent (if nothing else, i suspect something like SOLR-86 might be
handy) ... we should probably put solrj in the package name as well.
2) i wouldn't worry about having a special package for the exceptions ...
they've got exception in their name, no ones going to be confused.
3) I'm really not fond of "ParamNames.java" being a copy of the constants in
"SolrParams.java", or XML.java being copied, or the xpp jar being duplicated
... it seems like we should just pull in those (compiled) classes at build time
... but that would require that the whole Solr tree be checked out, and there
seems to be interest in making it possible to "svn checkout client/lang/impl"
and build that in isolation ... perhaps we could use svn:externals to pull in
specific utility classes and jars from other places in the tree? (although
based on what I've read today, branching for releases would be hard since all
of the svn:external props would have to be updated).
what do people think in general about how the client code can/should/shouldn't
depend on the core server code?
4) one thing we should really try to support in a client is executing query
requests against non-standard request handlers ... handlers that might take in
request params that we can't even imagine. The SolrQuery class has explicit
setters for many of the params that the built in request handlers support, but
there is no easy way for people to build other queries. I think it might make
sense if SolrQuery was an interface that just defined the methods needed by the
SolrClient -- probably just getQueryString(). Then their can be a
SimpleSolrQuery that has all of the setters in the current SolrQuery class,
possibly using a general baseclass with an impl of getQueryString that uses
some SolrParams...
public class AbstractSolrQuery implements SolrQuery {
protected abstract SolrParams getSolrParams();
public String getQueryString() {
... your current code, looping over getSolrParams() ...
}
}
5) what is the purpose of SolrClientStub ?
6) what is the purpose of SolrDocumentable being an empty interface? ... it
seems like you could replace SolrDocumentable, SolrDocument, and SolrDocumented
with something like this...
public interface SolrDocument {
public Map<String,Object> getSolrDocumentFields();
}
public abstract class SolrDocumented implements SolrDocument {
protected abstract SolrDocument getSolrDocument();
public Map<String,Object> getSolrDocumentFields() {
return getSolrDocument().getSolrDocumentFields()
}
}
Then you wouldn't need that instanceof code in SolrClientImpl
Note that we should probably support field and document boosts as well, but
field boosts don't really need to be specified in the Map since they apply to
the whole field and not the individual values, so we could just add...
public int getDocumentBoost();
public Map<String,Integer> getFieldBoosts()
...to SolrDocument.
7) The ResultsParser and QueryResults classes seem to suffer the same
limitation that i was mentioning about the SolrQuery class -- they assume a
very specific response structure (only one doc list, an optional facet block,
an optional highlighting block, an optional debug block) ... I think since the
ResultsParser already understands the all of the various tags that are used, it
should be easy to do this as long as the QueryResult object becomes a more
general container that any named data can be shoved into (just like
SolrQueryResponse is on the server side) ... then a "SimpleQueryResults" class
could be written that had the convenience methods that make sense when using
StandardRequestHandler or DisMaxRequestHandler.
8) There was a comment in SOLR-30 regarding the issue of that code only parsing
the XML response ... i think it's completely practical to focus on client code
which currently supports only the XmlResponseWriter output -- especially with
the solrj ResultsParser class currently having a single public method...
public QueryResults process( Reader reader ) throws SolrClientException,
SolrServerException, XmlPullParserException, IOException
...i think if we removed XmlPullParserException from that list of exceptions
(it could always be wrapped in a SolrClientException, or a new
SolrClientParseException) we have a really simple API where other ResultParser
classes could be written to handle JSON or what not down the road just by
adding a simple setResultParser to SolrClient.
> A simple Java client for updating and searching
> -----------------------------------------------
>
> Key: SOLR-20
> URL: https://issues.apache.org/jira/browse/SOLR-20
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
> Environment: all
> Reporter: Darren Erik Vengroff
> Priority: Minor
> Attachments: DocumentManagerClient.java, DocumentManagerClient.java,
> solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar,
> solr-client.zip, solr-client.zip, solr-client.zip, SolrClientException.java,
> SolrServerException.java
>
>
> I wrote a simple little client class that can connect to a Solr server and
> issue add, delete, commit and optimize commands using Java methods. I'm
> posting here for review and comments as suggested by Yonik.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
