Thanks Ryan. Comments below. On 7/5/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
I just took a quick look at solrsharp. I don't really have to use it yet, so this is not an in depth review. I like the templated SearchResults -- that seems useful.
That has proven to be extremely useful in our implementation. The template gives you the base stuff, and the implementation allows us to strongly type our results which makes programmatic usage easier to deal with. I don't quite follow the need to parse the SolrSchema on the client
side? Is that to know what fields are available? Could the same thing be achieved reading the response from the luke request handler? I only worry about it is as something to keep in sync with the java impl.
There's no real need to parse SolrSchema in order to execute searches or to add/update docs to the search index. The SolrSchema object was just a way of gathering schema definition and using it for whatever purpose it might make sense. It would be good to be able to change the request paths. While /select
and /update will usually work, it is possible to put stuff elsewhere.
This is a TODO item. The original library was constructed around the default paths, prior to the 1.1 release. The TODO item is actually one where named request handlers should be accessible objects that can be assigned to both searches and index updates. nitpick: FacetParameter.Zeros - should use facet.mincount instead.
(facet.mincount=0 is the same behavior)
Yep, another TODO item. I actually have this in place in development, pending a review of all facet parameters against the 1.2 release for accuracy. ryan