[ http://issues.apache.org/jira/browse/SOLR-30?page=comments#action_12421469 ] Philip Jacob commented on SOLR-30: ----------------------------------
Thanks for the comments. Here are my thoughts: 1) Good point. One approach for doing this would be to what Commons Configuration does. I could add methods to Field to perform getValueAsInteger(), getValueAsBoolean(), etc. These are basically just convenient methods. The other approach would be to change Field.value to Object instead of String. And then it's up to the client code to figure out what Object is (presumably using instanceof). So while I agree with your idea, I'm not sure what people think the best way to do this is. 2) JDOM - agreed. I just did it this way because writing DOM code takes me five times longer :) But, yes, it should go. Commons HttpClient, on the other hand, has a *lot* of useful stuff like multhreaded connection management and connection persistence. Even in medium-volume situations, these optimizations will make a difference. The prospect of implementing a subset of the functionality in Commons HttpClient is not an enviable task. 3) Actually, that was a question I had. Are those fields always guaranteed to be there in Solr's response? If not, then they ought to able to contain null so that means they could be Integers. If Solr guarantees that these fields will always be in the response, then they definitely could be ints. Other thoughts? > 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
