After thinking over your comments, I removed the facetHandler
completely, instead loading the Facets into a plain user cache, and
put the output work in a utils class similar to SolrPluginUtils. It
complicates the Term caching for me slightly, but it allows me to add
a "FacetUtils.doStandardFacet
On 7/20/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:
My biggest problem with going the extra mile for these types of
changes is that I simply don't have the time to do these types of
things right with unit tests, documentation, and so on.
The bar shouldn't be set too high for contributions eithe
I think solrconfig.xml makes more sense, leaving schema.xml to field
configuration and solrconfig.xml for system settings like caching and
request/response handling.
Erik
On Jul 20, 2006, at 5:58 PM, Yonik Seeley wrote:
Ok, a factory method to get the "default" query parser isn't
On Jul 20, 2006, at 5:38 PM, Chris Hostetter wrote:
: My application needs the QueryParser (by way of QueryParsing) to be
: set to AND mode, not the default of OR. There isn't currently a
: setting to control this.
I think by now everyone knows my prediliction for writing custom
RequestHandler
On 7/20/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
...i'm not saying I expect Erik to put in all the code to deal with all of
those now (unless you really want to Erik), just that it would be a good
idea if the config syntax for the default OP left room for them as
children of a larger so
Ok, a factory method to get the "default" query parser isn't a bad
idea (as long as we can live with a global config for it, and it
doesn't need to change for different handlers). Handlers like dismax
that know they need certain options could either not use the factory,
or reset the params it rea
: Maybe it belongs in solrconfig.xml as an option on the standard
: request handler init()... after all, it wouldn't apply to the dismax
: handler right (or could it...)? If we ever got a handler that
: accepted XML with explicit optional/required/prohibited, it wouldn't
: apply there either.
di
: My application needs the QueryParser (by way of QueryParsing) to be
: set to AND mode, not the default of OR. There isn't currently a
: setting to control this.
I think by now everyone knows my prediliction for writing custom
RequestHandlers -- but i agree that something like this would be a g
[
http://issues.apache.org/jira/browse/SOLR-29?page=comments#action_12422499 ]
Yonik Seeley commented on SOLR-29:
--
Do a switch based on uname, so most systems could use the existing cp -l ?
> backup utility does not work on OS X
> -
I'm for making it configurable (somehow)...
Maybe it belongs in solrconfig.xml as an option on the standard
request handler init()... after all, it wouldn't apply to the dismax
handler right (or could it...)? If we ever got a handler that
accepted XML with explicit optional/required/prohibited,
[
http://issues.apache.org/jira/browse/SOLR-29?page=comments#action_12422497 ]
Hoss Man commented on SOLR-29:
--
i'm a little worried about the possibility of "ln index/* snapshot/" failing
when there are a large number of files in the index and the
My application needs the QueryParser (by way of QueryParsing) to be
set to AND mode, not the default of OR. There isn't currently a
setting to control this.
I've added it locally using the patch below. Any objections to me
committing this?
I actually feel strongly that the default setti
Mike Klaas wrote:
On 7/19/06, Andrew May <[EMAIL PROTECTED]> wrote:
(although I have
wondered whether it would be possible for the default highlighted
fields to be derived
from the query in some way).
It wouldn't be too hard to extract : queries in
StandardRequestHandler. Do you have anyth
that's a very good way to do it. You could also use
SolrIndexSearcher.numDocs -- it is esentially the same thing, but in the
future there may be optimizations that can be done to eliminate the
construction of one DocSet (if the other one already exists)
Thank you for the tip -- I will take a lo
[
http://issues.apache.org/jira/browse/SOLR-29?page=comments#action_12422433 ]
Bill Au commented on SOLR-29:
-
Exactly. That's why I am leaning towards not using hard links for backup.
By the way,
ln index/* snapshot/
does work on OS X.
I will op
:DocSet valueDocSet = req.getSearcher().getDocSet(item.getQuery());
:long count = valueDocSet.intersectionSize(results);
:
: Is this the preferred way to obtain such a count, or ithere another
that's a very good way to do it. You could also use
SolrIndexSearcher.numDocs -- it is
16 matches
Mail list logo
