[
https://issues.apache.org/jira/browse/SOLR-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651598#action_12651598
]
[EMAIL PROTECTED] edited comment on SOLR-877 at 11/28/08 8:45 AM:
-------------------------------------------------------------
Looks useful, esp for distributed idf when we get around to it.
A quick review:
- "terms.fl", fl normally stands for field list. Would this make more sense as
"terms.f"?
- strings are returned instead of integers for the term count (it's even more
obvious in JSON output)
- how does one ask for "all terms after foo?" the docs suggest that upper or
rows *must* be set... is the only way to set a really high rows value? If so,
allowing terms.rows=-1 for "unlimited" might be nicer.
Actually, this is very much like faceting.... perhaps we should use the same
parameters:
terms.field
terms.offset
terms.limit
terms.mincount (future)
terms.sort (future)
If this is to be useful for distributed search, it needs to be able to handle
the direct specifications of terms in multiple fields. We necessarily need to
implement this now, but we should think about having an output format that
doesn't need to be deprecated when it is added. At a minimum it seems like
there should be an extra level.... something like
{code}
"terms" = {
"myfield" = { "foo"=10, "bar"=5, ...}
}
{code}
Or if we want to get even more like faceting with the output:
{code}
"terms" = {
"fields" = {
"myfield" = {"foo"=10,...}
}
}
{code}
- "terms.upr.incl" and "terms.lwr.incl" hurt the eyes a little since we already
have "lower" and "upper" in the names of other terms - seems error prone (but
this is a purely aesthetic thing).
- This is supposedly useful for auto suggest - how do I go about asking for all
terms starting with "abc"? Shouldn't there be a "terms.prefix" (just like
faceting)?
was (Author: [EMAIL PROTECTED]):
Looks useful, esp for distributed idf when we get around to it.
A quick review:
- "terms.fl", fl normally stands for field list. Would this make more sense as
"terms.f"?
- strings are returned instead of integers for the term count (it's even more
obvious in JSON output)
- how does one ask for "all terms after foo?" the docs suggest that upper or
rows *must* be set... is the only way to set a really high rows value? If so,
allowing terms.rows=-1 for "unlimited" might be nicer.
Actually, this is very much like faceting.... perhaps we should use the same
parameters:
terms.field
terms.offset
terms.limit
terms.mincount (future)
terms.sort (future)
If this is to be useful for distributed search, it needs to be able to handle
the direct specifications of terms in multiple fields. We necessarily need to
implement this now, but we should think about having an output format that
doesn't need to be deprecated when it is added. At a minimum it seems like
there should be an extra level.... something like
{code}
"terms" = {
"myfield" = { "foo"=10, "bar"=5, ...}
}
{code}
Or if we want to get even more like faceting with the output:
{code}
"terms" = {
"fields" = {
"myfield" = {"foo"=10,...}
}
}
{code}
> Access to Lucene's TermEnum capabilities
> ----------------------------------------
>
> Key: SOLR-877
> URL: https://issues.apache.org/jira/browse/SOLR-877
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-877.patch, SOLR-877.patch
>
>
> I wrote a simple SearchComponent on the plane the other day that gives access
> to Lucene's TermEnum capabilities. I think this will be useful for doing
> auto-suggest and other term based operations. My first draft is not
> distributed, but it probably should be made to do so eventually.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
