: Do you think the package name should change?
:
: org.apache.solr.client.SolrClient
: vs
: org.apache.solr.client.solrj.SolrClient;
yeah ... that way if down the road someone comes up with a radically new
Java API (that we can't even fathom yet) they can call it "solrad" and put
it in clients/java/solarad and make the packages be
"org.apache.solr.client.solarad.* and we can be sure there's no potential
for class name collision.
(this is the same model that the Lucene-Java tries to use with contrib
packages: each contribs lives in a seperate directory, but uses unique
packagenames)
: maybe the main ant task could copy a few files from:
: /src/java/org/apache ...
: /client/java/org/apache ...
or (as i think someone else mentioned somewhere) refactor some of the code
in src/java so that it compiles into a utility jar that can be shared by
teh war and the client code.
: Perhaps the client should parse the results into a 'NamedList'...
it would certinaly make sense since that's the most direct model of the
data (a list of pairs)
: > 6) what is the purpose of SolrDocumentable being an empty interface?
: > ... it seems like you could replace SolrDocumentable, ...
: >
: > 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()
: > }
: > }
:
: aaah, if only java allowed multiple inheritance!
:
: The two versions arose out of converting existing projects to use
: solr. In some cases it made sense to have the objects make their own
: document, in others id does not. Originally, i had the structure you
: suggest, but the 'SolrDocumented' objects are already in a fixed
: hierarchy.
ah ... in other words you already have Objects in an inheritence
hierarchy that you want to pass directly to the SolrClient by making them
impliment a simple interface that says they know how to return a
SolrDocument ... i get that you can't change their base class, but why
is it neccessary to pass the orriginal object to the SolrClient? couldn't
we eliminate the SolrDocumented and SolrDocumentable interfaces completly
just be asking clients to write...
UsersCustomClass {
SolrDocument someMethodOfTheirChoice();
}
...
UsersCustomClass bizObject = ...
solrClient.add(bizObject.someMethodOfTheirChoice());
...instead of...
UsersCustomClass implements SolrDocumented{
SolrDocument getSolrDocument();
}
...
UsersCustomClass bizObject = ...
solrClient.add(bizObject);
?
: If it were more then one instanceof I would be more worried about
: it... but i'm open to suggestion.
technically there's two...
if( document instanceof SolrDocument ) {
fields = ((SolrDocument)document).getSolrDocumentFields();
}
else if( document instanceof SolrDocumented ) {
fields =
((SolrDocumented)document).getSolrDocument().getSolrDocumentFields();
}
else {
throw new RuntimeException( "don't know about SolrDocumentable type: " +
document.getClass().getName() );
..the danger being we expose an interface, tell people they can pass
instances of it to a method, and then reject their instance if it's not
one of the two magic interfaces ... not a clean API.
if ther's really a need for SolrDocumented, we should make two seperate
interfaces, with two seperate add methods (one delegating to the other
after fetching the SolrDocument from the SolrDocumented.
-Hoss
