Re: svn commit: r507825 - /lucene/solr/trunk/src/java/org/apache/solr/handler/IndexInfoRequestHandler.java

[Erik Hatcher <er...@ehatchersolutions.com>]

Any objections?

CC'ing ruby-dev:

The error I get is this:
$ irb
irb(main):002:0> YAML.load YAML.dump(1171485783523)
TypeError: allocator undefined for Bignum
         from /opt/local/lib/ruby/1.8/yaml.rb:133:in `transfer'
         from /opt/local/lib/ruby/1.8/yaml.rb:133:in `load'
         from (irb):2

Where does YAML come into play?  Well, I serialize out the response  
obtained from IndexInfoRequestHandler as a .yml file but could not  
load it back with the error just shown.  (for stats gathering as I  
load the library data: 200k documents indexed, hideous facets data,  
Solr rocking big time, 108ms response time returning the top 20 of  
each facet).

	Erik




On Feb 15, 2007, at 12:33 AM, ehatcher@apache.org wrote:

> Author: ehatcher
> Date: Wed Feb 14 21:33:11 2007
> New Revision: 507825
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=507825
> Log:
> Adjust Lucene version value to be a String rather than an numeric.   
> I found a case with Ruby where the numeric
> was too big to laod when serialiized to a YAML file (maybe this is  
> an edge case?).  It is unlikely that a client
> needs to use this as a numeric anyway, but rather as a comparison  
> against later calls to the IndexInfoRequestHandler.
>
>
>
> Modified:
>     lucene/solr/trunk/src/java/org/apache/solr/handler/ 
> IndexInfoRequestHandler.java
>
> Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/ 
> IndexInfoRequestHandler.java
> URL: http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/ 
> apache/solr/handler/IndexInfoRequestHandler.java? 
> view=diff&rev=507825&r1=507824&r2=507825
> ====================================================================== 
> ========
> --- lucene/solr/trunk/src/java/org/apache/solr/handler/ 
> IndexInfoRequestHandler.java (original)
> +++ lucene/solr/trunk/src/java/org/apache/solr/handler/ 
> IndexInfoRequestHandler.java Wed Feb 14 21:33:11 2007
> @@ -58,10 +58,10 @@
>        }
>        rsp.add("fields", fields);
>
> -      Map<String,Number> indexInfo = new HashMap<String,Number>();
> +      Map<String,Object> indexInfo = new HashMap<String,Object>();
>        indexInfo.put("numDocs", reader.numDocs());
>        indexInfo.put("maxDoc", reader.maxDoc());
> -      indexInfo.put("version", reader.getVersion());
> +      indexInfo.put("version", Long.toString(reader.getVersion()));
>        // indexInfo.put("age", );  // computed from  
> SolrIndexSearcher.openedAt?
>
>        rsp.add("index", indexInfo);
>

Re: svn commit: r507825 - /lucene/solr/trunk/src/java/org/apache/solr/handler/IndexInfoRequestHandler.java

[Erik Hatcher <er...@ehatchersolutions.com>]

On Feb 15, 2007, at 2:41 PM, Yonik Seeley wrote:
> On 2/15/07, Erik Hatcher <er...@ehatchersolutions.com> wrote:
>> Any objections?
>
> Nope, version being a string sounds fine... as you say, it's only used
> for comparison.
> "age" or "openedAt" if expressed in milliseconds should be numberics
> though... is this a YAML bug?

Seems like a YAML bug, or a misunderstanding I have on how it should  
work.  And again, the YAML thing was really a bizarre edge case of my  
own where I'm persisting some data from Solr's response as-is.

?qt=indexinfo doesn't currently return either age or openedAt, though  
there is a placeholder in there for it though I wasn't sure at the  
time how to compute that.

	Erik

Re: svn commit: r507825 - /lucene/solr/trunk/src/java/org/apache/solr/handler/IndexInfoRequestHandler.java

[Yonik Seeley <yo...@apache.org>]

On 2/15/07, Erik Hatcher <er...@ehatchersolutions.com> wrote:
> Any objections?

Nope, version being a string sounds fine... as you say, it's only used
for comparison.
"age" or "openedAt" if expressed in milliseconds should be numberics
though... is this a YAML bug?

-Yonik

Re: svn commit: r507825 - /lucene/solr/trunk/src/java/org/apache/solr/handler/IndexInfoRequestHandler.java

[Yonik Seeley <yo...@apache.org>]

On 2/15/07, Erik Hatcher <er...@ehatchersolutions.com> wrote:
> Any objections?

Nope, version being a string sounds fine... as you say, it's only used
for comparison.
"age" or "openedAt" if expressed in milliseconds should be numberics
though... is this a YAML bug?

-Yonik