: I have committed the modified implementation based on Hoss' feedback,
: including the addition of the setting to the example schema.xml and
: to the wiki documentation.
:
: Let me know if anything needs to be touched up to polish this off.
Thanks Erik, it looks pretty good to me.
-Hoss
I have committed the modified implementation based on Hoss' feedback,
including the addition of the setting to the example schema.xml and
to the wiki documentation.
Let me know if anything needs to be touched up to polish this off.
Many thanks for the solid leadership and thorough attention
On 7/22/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
i have no strong opinion. my gut says that as it pertains to the
"default" query parser, it makes sense in the schema
Sounds fine to me. I have no string preference either.
-Yonik
: Ideally, most of the info one needs to understand and query and index
: would be in the schema.xml (hence it makes sense for copyField to be
: there). Since this will affect the "language" of the query parser, it
: can make sense to go in schema.xml
:
: But if a case were ever made for configur
On 7/21/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:
But are we sure we want that in schema.xml? Or should it be in
solrconfig.xml instead?
Hmmm, a case could be made for either
Ideally, most of the info one needs to understand and query and index
would be in the schema.xml (hence it makes
On Jul 21, 2006, at 5:01 AM, Chris Hostetter wrote:
: > my one suggestion would be that we should support schema.xml
: > declarations
: > for all of the "setable" properties of the Lucene QueryParser...
: >
: > fuzzyMinSim="0.5"
: >fuzzyPrefixLength="2"
: > my one suggestion would be that we should support schema.xml
: > declarations
: > for all of the "setable" properties of the Lucene QueryParser...
: >
: > fuzzyMinSim="0.5"
: >fuzzyPrefixLength="2"
: >locale="???"
: >
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
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,
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
16 matches
Mail list logo