You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Erik Hatcher <er...@ehatchersolutions.com> on 2007/02/01 04:54:29 UTC

Re: SV: Re: SOLR-116

On Jan 30, 2007, at 5:33 AM, Antonio Eggberg wrote:
> Erik Hatcher <er...@ehatchersolutions.com> skrev:
> So, no, the current information provided by this handler does not
> contain frequency information.  I'd be happy to consider patches that
> allow it to provide more information, though I'd like to keep the
> basic index information request as succinct as possible, using
> additional parameters to output more details if requested.
>
>  Erik and Chris!
>
> Thanks again for the clarification. It helps a lot. I am still  
> trying to get my head around Solr and Solrb. Lot of  
> new ..cool..things! It would me greatly if any of you could beef up  
> at least the solrb RDOC i.e. beside stubbs with examples etc. I  
> know its a bit early in the development but
> its difficult to get into API's without docs. I would love to  
> contribute once  we have some basics there plus when I get a bit  
> more comfortable in Solr.

solrb rdoc... indeed we'll beef it up.  If you have specific  
questions, please ask and that'll help prioritize what needs to be  
covered sooner rather than later.

However, even better than documentation is real-world working example  
code.  You'll find that in the README file and in the quite robust  
test case (100% code coverage, still!).  The unit test cases are  
sometimes contrived to exercise an edge case in the code and may not  
be useful for copy/paste, but the functional tests are end-to-end  
tests that hit a real Solr instance.

	Erik


solrb documentation (was Re: SV: Re: SOLR-116)

Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 1, 2007, at 6:47 AM, Zaheed Haque wrote:
> I think trying to tackle two problem (Learning Solr as well as
> solrb/flare) at the
> same time is giving the problem. While I was writing the i18n unit  
> test I found
> out the 100% test cov. thats really cool. Now in terms of docs.. I
> think it would
> be great if I have a
>
> - TODO file under client/ruby/solrb. What I mean is that - lot of  
> times
> I find information in wiki which applies to Solr but I don't know  
> if it applies
> to solr-ruby-api. So it would be nice to have a TODO file (Things  
> that is
> not available in solr-ruby yet. Makes my life easier.

We have our own solrb TODO list on the wiki: <http://wiki.apache.org/ 
solr/solrb/ToDo>, also note the "rake todo" task that will produce a  
list of all the TBD/TODO/FIXME lines in the code.

> - I am completely lost in terms of facets.. I would love to have  
> some more info
> about it. I couldn't follow the facet's part of the code when i was
> looking at the test/unit/standard_request.rb and standard_response.rb,
> It would be nice if
> there were some explanation regarding facets in the .rb files.

Quite fair enough.

However, rather than reinvent the wheel, have you read these?

  - <http://wiki.apache.org/solr/SolrFacetingOverview>
  - <http://wiki.apache.org/solr/SimpleFacetParameters>

Granted the difference is that through solrb we map more readable  
names to the arguments, along a sensible data-structure of parameters:

     request = Solr::Request::Standard.new(:query => 'query',
        :facets => {
          :fields => [:genre,
                      # field that overrides the global facet parameters
                      {:year =>
                         {:limit => 50, :mincount => 0, :missing =>  
false, :sort => :term, :prefix=>"199"}}],
          :queries => ["q1", "q2"],
          :prefix => "cat",
          :limit => 5, :zeros => true, :mincount => 20, :sort  
=> :count  # global facet parameters
         }
     )

I have to stop and laugh when I see this versus the vastly more  
succinct query string this generates, and wonder if the syntactic  
sugar is really worth it :)  One nicety is that nested values like a  
field-specific override of the mincount is easier to visually parse  
with the Ruby code.

So while I'm in complete agreement with you that solrb's rdocs need  
lots of improvements, I also don't want the docs to be a copy of what  
Solr docs already explain nicely.

> If you prefer, what I could do is comment the code as I see it based
> on the functional
> test and then you can edit it this way we could beef up the doc rather
> quick. Its not that
> many files so I could give it a shot by end day tomorrow. Off course
> except Facets :-)

Sure thing!  Patches are always welcome, and even more welcome when  
they are documentation patches :)

	Erik


Re: SV: Re: SOLR-116

Posted by Zaheed Haque <za...@gmail.com>.
On 2/1/07, Erik Hatcher <er...@ehatchersolutions.com> wrote:
>
> On Jan 30, 2007, at 5:33 AM, Antonio Eggberg wrote:
> > Erik Hatcher <er...@ehatchersolutions.com> skrev:
> > So, no, the current information provided by this handler does not
> > contain frequency information.  I'd be happy to consider patches that
> > allow it to provide more information, though I'd like to keep the
> > basic index information request as succinct as possible, using
> > additional parameters to output more details if requested.
> >
> >  Erik and Chris!
> >
> > Thanks again for the clarification. It helps a lot. I am still
> > trying to get my head around Solr and Solrb. Lot of
> > new ..cool..things! It would me greatly if any of you could beef up
> > at least the solrb RDOC i.e. beside stubbs with examples etc. I
> > know its a bit early in the development but
> > its difficult to get into API's without docs. I would love to
> > contribute once  we have some basics there plus when I get a bit
> > more comfortable in Solr.
>
> solrb rdoc... indeed we'll beef it up.  If you have specific
> questions, please ask and that'll help prioritize what needs to be
> covered sooner rather than later.

Cool. Please see below.

> However, even better than documentation is real-world working example
> code.  You'll find that in the README file and in the quite robust
> test case (100% code coverage, still!).  The unit test cases are
> sometimes contrived to exercise an edge case in the code and may not
> be useful for copy/paste, but the functional tests are end-to-end
> tests that hit a real Solr instance.

I think trying to tackle two problem (Learning Solr as well as
solrb/flare) at the
same time is giving the problem. While I was writing the i18n unit test I found
out the 100% test cov. thats really cool. Now in terms of docs.. I
think it would
be great if I have a

- TODO file under client/ruby/solrb. What I mean is that - lot of times
I find information in wiki which applies to Solr but I don't know if it applies
to solr-ruby-api. So it would be nice to have a TODO file (Things that is
not available in solr-ruby yet. Makes my life easier.
- I am completely lost in terms of facets.. I would love to have some more info
about it. I couldn't follow the facet's part of the code when i was
looking at the test/unit/standard_request.rb and standard_response.rb,
It would be nice if
there were some explanation regarding facets in the .rb files.

If you prefer, what I could do is comment the code as I see it based
on the functional
test and then you can edit it this way we could beef up the doc rather
quick. Its not that
many files so I could give it a shot by end day tomorrow. Off course
except Facets :-)

Cheers
Zaheed