Solr 1.2

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Solr 1.2

Ryan McKinley
I have finished adding the major things I wanted in solr1.2.  I think
everything followed the http://wiki.apache.org/solr/CommitPolicy except
the unlisted one that its nice to keep the time/changes ratio long
enough that you can grock whats going on through osmosis ;)

Other patches on the 'popular' list that I know about and think are
stable enough to consider:
   SOLR-176
   SOLR-142 (if it can/should be added independent of jsp integration)

It is maybe worth waiting for something like SOLR-85 and integrating the
admin handlers with the admin jsp, but I won't have much time till after
the 10th.

- - - - -

Open trivial questions:

1. should we remove IndexInfoRequestHandler.java?  It is a subset of the
LukeRequestHandler, but IIRC it was implemented for the internet archive.

2. Should we move DisMaxRequestHandler.java and
StandardRequestHandler.java to o.a.s.handler -- leaving a @Deprecated
class in its place.  This would give people a way to extend these
classes and gives us a way to clean up o.a.s.request in future releases?

3. Can you take a look at the output from o.a.s.handler.admin.* and make
sure the output could be styled with xslt.  Eric, can you make sure it
is using SimpleOrderedMap wherever appropriate for flare?


Regarding the logo... I asked both Juan and Nick to take another look at
the logo - with an eye for something "professional"; But I don't think
we should rush it for solr1.2 unless something magically appears.

good good
ryan




Reply | Threaded
Open this post in threaded view
|

Re: Solr 1.2

Erik Hatcher

On Apr 29, 2007, at 7:39 PM, Ryan McKinley wrote:
> Open trivial questions:
>
> 1. should we remove IndexInfoRequestHandler.java?  It is a subset  
> of the LukeRequestHandler, but IIRC it was implemented for the  
> internet archive.

I implemented that request handler for Flare, so it can introspect on  
the field names to show facets for *_facet fields, and search on the  
*_text fields.  So yeah, we can deprecate IndexInfoRequestHandler in  
lieu of cool hand Luke.

> 3. Can you take a look at the output from o.a.s.handler.admin.* and  
> make sure the output could be styled with xslt.  Eric, can you make  
> sure it is using SimpleOrderedMap wherever appropriate for flare?

It may be a while before I get a chance to take a good look at this.  
I'm sure any data being returned is fine to read with solr-ruby, it  
just might be more awkward to navigate.  So not a huge deal for me  
either way.

        Erik



Reply | Threaded
Open this post in threaded view
|

Re: Solr 1.2

Ryan McKinley
Erik Hatcher wrote:

>
> On Apr 29, 2007, at 7:39 PM, Ryan McKinley wrote:
>> Open trivial questions:
>>
>> 1. should we remove IndexInfoRequestHandler.java?  It is a subset of
>> the LukeRequestHandler, but IIRC it was implemented for the internet
>> archive.
>
> I implemented that request handler for Flare, so it can introspect on
> the field names to show facets for *_facet fields, and search on the
> *_text fields.  So yeah, we can deprecate IndexInfoRequestHandler in
> lieu of cool hand Luke.
>

Excellent.  I deprecated the class, but I'll let you delete the file if
you are no longer using it.  (It was added since 1.1 so unless we want
to support it, it should probably go)


>> 3. Can you take a look at the output from o.a.s.handler.admin.* and
>> make sure the output could be styled with xslt.  Eric, can you make
>> sure it is using SimpleOrderedMap wherever appropriate for flare?
>
> It may be a while before I get a chance to take a good look at this.  
> I'm sure any data being returned is fine to read with solr-ruby, it just
> might be more awkward to navigate.  So not a huge deal for me either way.
>

ok, i just wanted to make sure I'm not doing something awful -- I don't
think i am.