On 9/22/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: 2) If the user specifies a filter, the query still makes sense. : Perhaps for queries that have fq but not q, dismax should use a : MatchAllDocsQuery() and a filter. I suspect this may be a problem, mmmm.... saying it makes sense depends on how you look at it ... you could do a MatchAllDocsQuery or you could just use the DocSet generated by the "fq" to get a DocList ... but either way does that really "make sense" given that there is no scoring information? ... how do you fairly factor in things like the bf and bq if you have no "real" scores for the matching documents?
I was just imagining an arbitrary (though consistent) ordered list of docs.
: churn. Perhaps it would be better to detect this case before reaching : solr, and use a StandardRequestHandler with the filters as a lucene : query? I definitely think it's better to have clients deal with the "no query" situation, but most of the time they'd probably just skip the hit to Solr alltogether. If there are cases where we want dismax to support a "match all" or "match all with fq" I'd rather see us add support using a special option that triggers the behavior then to make clients conditionally hit Standard with the fq => q, becuase that want work for installations that put the "fq" in init params so their clients can be agnostic.
This fall-through behaviour is what I ended up implementing on the client side. DisMax needn't take care of _all_ my edge cases <g>.
...actually, i can see where this would make a lot of sense ... supporting filtered "browsing" or filtered "searching" of the full index using the same request structure, just leaving off the "q" if you are "browsing" ... if bq and bf are used then even sorting by score still makes sense.
True, though it isn't hard to throw together a custom request handler or use the old lucene trick before MatchAllDocs existed (index a constant field or all docs). Thanks, -MIke
