solrsharp thoughts

[Ryan McKinley <ry...@gmail.com>]

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.

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.

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.

nitpick: FacetParameter.Zeros - should use facet.mincount instead. 
(facet.mincount=0 is the same behavior)


ryan

Re: solrsharp thoughts

[Jeff Rodenburg <je...@gmail.com>]

Thanks Ryan.  Comments below.

On 7/5/07, Ryan McKinley <ry...@gmail.com> 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
>