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

Reply via email to