NamedList and SearchComponent in practice

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

Suppose you have a custom SearchComponent that wants to muck with the  
response built prior?   You can replace values in a NamedList, but you  
can't remove them.  Any reason we can't add this to NamedList?

  /**
   * Removes the name/value pair at the specified index.
   * @return the value at the index removed
   */
  public T remove(int idx) {
    int index = (idx<<1);
    nvPairs.remove(index);
    return (T)nvPairs.remove(index);  // same index, as things shifted  
in previous remove
  }

It brings up an interesting philosophical question - should a  
SearchComponent even be allowed to muck with the response at all,  
other than adding to it?   But for now I'm fine with letting  
components do what they want with the response.

	Erik

Re: NamedList and SearchComponent in practice

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

On Aug 20, 2008, at 4:21 PM, Erik Hatcher wrote:
> On Aug 20, 2008, at 3:45 PM, Grant Ingersoll wrote:
>> Seems reasonable to have a remove function
>
> Cool.  Any objections to me committing that before the 1.3 release?

Couldn't resist... committed with unit test.

	Erik

Re: NamedList and SearchComponent in practice

[Chris Hostetter <ho...@fucit.org>]

: I don't quite agree.  Actually my particular use case would be easier to
: achieve if QueryComponent was subclassable and overridable in the query/docset

making existing components easier to subclass and customize should be a 
goal ... better ot have people wriging small little subclasses then 
cut/paste big chunks of code into new components.

: > In my mind, the response isn't officially the response until it leaves Solr
: > (or at least not until it leaves the component handling part.)
: 
: Yeah, but that gets messy if components are just tossed in to mess with work
: other components did.  It would make more sense to replace the components
: rather than add a MuckingComponent to the end.  Making QueryComponent more
: easily subclassable will make my life easier at least.

There's a difference between "allowing" mucking, "encouraging" mucking, 
and "practicing" mucking.

Components that are included in Solr releases shouldn't do any overt 
mucking themselves, and they should be easily subclassed to discourage 
people from mucking by offering easy ways to achieve the same goal -- but 
i don't see a need for Solr to try and prevent third party components from 
mucking with things if people really want them to.

(which falls in the: if they want to take hte rope we give them and hang 
themselves fine, but we shouldn't tie it into a noose for them in 
advance)



-Hoss

Re: NamedList and SearchComponent in practice

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

On Aug 20, 2008, at 3:45 PM, Grant Ingersoll wrote:
> Seems reasonable to have a remove function

Cool.  Any objections to me committing that before the 1.3 release?

>> It brings up an interesting philosophical question - should a  
>> SearchComponent even be allowed to muck with the response at all,  
>> other than adding to it?   But for now I'm fine with letting  
>> components do what they want with the response.
>
> I think they should be able to change them.  For example, I could  
> imagine a security component that goes through and removes results  
> (assuming this wasn't built into searches), or an automated  
> relevance feedback mechanism.

My use case is much like a feedback mechanism... basically a  
QueryComponent that changes the query if there are no results found.    
It seems to me the better fit is for this type of mechanism is a  
"query" component replacement, not an additional component that mucks  
with the query and doc set  (think about faceting, etc, that need the  
docset to operate upon).

>  Seems like Solr shouldn't prevent anyone from doing mucking if they  
> want to muck.  Such is the nature of a plugin mechanism.

I don't quite agree.  Actually my particular use case would be easier  
to achieve if QueryComponent was subclassable and overridable in the  
query/docset stuff rather than doing that work and jamming the stuff  
into the response without a subclass having a chance.  So I'll  
probably refactor QueryComponent a bit and put in a protected method  
that can be overridden.

> In my mind, the response isn't officially the response until it  
> leaves Solr (or at least not until it leaves the component handling  
> part.)

Yeah, but that gets messy if components are just tossed in to mess  
with work other components did.  It would make more sense to replace  
the components rather than add a MuckingComponent to the end.  Making  
QueryComponent more easily subclassable will make my life easier at  
least.

	Erik

Re: NamedList and SearchComponent in practice

[Grant Ingersoll <gs...@apache.org>]

On Aug 20, 2008, at 2:19 PM, Erik Hatcher wrote:

> Suppose you have a custom SearchComponent that wants to muck with  
> the response built prior?   You can replace values in a NamedList,  
> but you can't remove them.  Any reason we can't add this to NamedList?
>
> /**
>  * Removes the name/value pair at the specified index.
>  * @return the value at the index removed
>  */
> public T remove(int idx) {
>   int index = (idx<<1);
>   nvPairs.remove(index);
>   return (T)nvPairs.remove(index);  // same index, as things shifted  
> in previous remove
> }

Seems reasonable to have a remove function

>
>
> It brings up an interesting philosophical question - should a  
> SearchComponent even be allowed to muck with the response at all,  
> other than adding to it?   But for now I'm fine with letting  
> components do what they want with the response.

I think they should be able to change them.  For example, I could  
imagine a security component that goes through and removes results  
(assuming this wasn't built into searches), or an automated relevance  
feedback mechanism.  Seems like Solr shouldn't prevent anyone from  
doing mucking if they want to muck.  Such is the nature of a plugin  
mechanism.

In my mind, the response isn't officially the response until it leaves  
Solr (or at least not until it leaves the component handling part.)

-Grant

Re: NamedList and SearchComponent in practice

[Sean Timm <ti...@aol.com>]

You can replace them, but it is not pretty.  Also, the results are in at 
least two places in the ResponseBuilder which seems a bit odd.

    //replace the DocList in ResponseBuilder
    DocList dl = new DocSlice(docs.offset(), kept, keepDocs, keepScores, 
docs.matches(), docs.maxScore());
    DocListAndSet dlas = new DocListAndSet();
    dlas.docList = dl;
    dlas.docSet = rb.getResults().docSet;
    rb.setResults(dlas);
    NamedList nl = rb.rsp.getValues();
    nl.setVal(nl.indexOf("response",0),rb.getResults().docList);

-Sean

Erik Hatcher wrote:
> Suppose you have a custom SearchComponent that wants to muck with the 
> response built prior?   You can replace values in a NamedList, but you 
> can't remove them.  Any reason we can't add this to NamedList?
>
>  /**
>   * Removes the name/value pair at the specified index.
>   * @return the value at the index removed
>   */
>  public T remove(int idx) {
>    int index = (idx<<1);
>    nvPairs.remove(index);
>    return (T)nvPairs.remove(index);  // same index, as things shifted 
> in previous remove
>  }
>
> It brings up an interesting philosophical question - should a 
> SearchComponent even be allowed to muck with the response at all, 
> other than adding to it?   But for now I'm fine with letting 
> components do what they want with the response.
>
>    Erik