Don't turn off the query component in those cases. In these cases, the QC identifies what docs are to be used, just as in a user based query. Just think of those other components as clients of the QC output, and I think it makes sense. The application will know whether it needs to deal with results or not. I suppose we could have something that says "run the query and make the results available to other components, but don't bother writing them out".

On Oct 21, 2008, at 11:33 AM, Noble Paul നോബിള്‍ नोब्ळ् wrote:

hi Grant,
There may be cases where the user may not be interested in the
documents but there may be other components which are interested in
the search results. In 'tvrh' is an example. How do we take care of
that?

On Tue, Oct 21, 2008 at 8:59 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
FWIW, my last patch on SOLR-769 adds a check to see if QC is enabled, with the default param set to true. Thus, you can send in &query=false and it
skips it.


On Oct 21, 2008, at 11:21 AM, Noble Paul നോബിള്‍ नोब्ळ् wrote:

+1
I can forsee a lot of components which does not need the
QueryComponent. SOLR-706 being one.



On Tue, Oct 21, 2008 at 8:39 PM, Ryan McKinley <[EMAIL PROTECTED]> wrote:

On Oct 21, 2008, at 8:17 AM, Grant Ingersoll wrote:


On Oct 20, 2008, at 11:35 PM, Otis Gospodnetic wrote:

This is related to something I must have only day dreamed (dreamt?)
about, but not actually mentioned on solr-dev.
My feeling is we are moving Solr in a direction of a more general web service that can host various NLP and ML components, and no longer only
do
IR/Lucene. We see that with a few patches that Grant is cooking, I
think
we'll see that in the Solr+Mahout marriage down the road, and so on.

I somewhat agree, but I hesitate to go so far as saying a "general web
service".

I won't suggest that solr is (or should be) a general web service, but wt=json/xml/python + RequestHandler makes a pretty nice cross platform
interface all on its own.


I see Solr as a pretty nice platform for doing things like NLP/ ML (see
the
AnalysisRequestHandler, TermVectorComponent, ClusteringComponent,
LukeReqHandler, FacetingComp., Payloads, etc.), but I mostly view them
as
enhancing search/navigation. That is, things like clustering/ faceting (they are closely related), named entity recognition, search, etc. all
act
as organizing components for structured and unstructured data.
Expressing
my vision for Solr (and actually, the Lucene TLP, too, if I put on my
PMC
hat) it's one that aims to bring coherence to (structured and
unstructured)
content. This starts with search as a foundation, since the indexing process creates much of the information that empowers the others. I
think
once you see the flexible indexing stuff added to Lucene Java, we'll see
even more opportunity for making Solr even more powerful in these
regards.


agree.




Is it time to start thinking about Solr sa a server for IR and ML and
NLP
tasks and see how the tightly coupled Lucene can be made
more....pluggable?

Yeah, this is what the Solr 2.0 thread that Yonik started a few weeks
ago
aims to discuss, along with scalability/fault tolerance.  More
important,
for me anyway, is the decoupling of the configuration. For instance, I
see
no reason why IndexSchema needs to know anything about an InputStream.

also agree. The biggest challenge for 2.0 is decoupling configuration

As for Lucene, it's really quite good at serving as the backend
store/enabler for all these tasks.


I have not messed with it yet, but perhaps also HBase...


At any rate, the question still remains as to how best to handle the
QueryComponent :-)


aaah, your question!

I see two options:
1. If no other component needs docList or docSet and the query is empty,
then skip the QueryComponent
2. add a 'runQuery' param (or somethign like that) and default to true.
It
can be turned off when not necessary.

I like option 1 better.

ryan






--
--Noble Paul

--------------------------
Grant Ingersoll
Lucene Boot Camp Training Nov. 3-4, 2008, ApacheCon US New Orleans.
http://www.lucenebootcamp.com


Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ













--
--Noble Paul

--------------------------
Grant Ingersoll
Lucene Boot Camp Training Nov. 3-4, 2008, ApacheCon US New Orleans.
http://www.lucenebootcamp.com


Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ









Reply via email to