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
