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