i think it will impact a lot of people ... everyone currently using the
standard request handler (which is certainly more then the number of
people using json, and we made sure there was a backwards compatible
option for them)
i'm certianly okay however with saying that if they want the backward
: > it could .. but it wouldn't need to be specified as part of every request
: > it could be baked into the solrconfig .. we could even make the default
: > behavior be to not bother with the ";" syntax, and document in the
: > CHANGES.txt that people who want the old behavior need to explicitly
it could .. but it wouldn't need to be specified as part of every request
it could be baked into the solrconfig .. we could even make the default
behavior be to not bother with the ";" syntax, and document in the
CHANGES.txt that people who want the old behavior need to explicitly add
some defaul
: "uncool" comment was, er, uncool, but the motivation was that AFAIK in
: no other place does SOLR make this distinction, an assumption based on
: SolrParams not having an API to test for param existence and being
: explicitly coded around nonexistence and null being equatable; meanwhile
: elsewh
[
https://issues.apache.org/jira/browse/SOLR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Coda Hale updated SOLR-171:
---
Attachment: solr-boosts.diff
Includes unit tests.
> Add per-doc and per-field boosts
> ---
Add per-doc and per-field boosts
Key: SOLR-171
URL: https://issues.apache.org/jira/browse/SOLR-171
Project: Solr
Issue Type: Improvement
Components: clients - ruby - flare
Reporter: Coda
: I agree that a user of the sort parameter wouldn't want their query
: string munged as a side effect of not supplying sort, or setting it to
: blank, on some request. But having an explicit parameter to control
: every aspect of legacy behavior could certainly lead to nasty parameter
: bloat...
On Feb 22, 2007, at 4:50 PM, Chris Hostetter wrote:
i agree overplaning is bad ... i just want to ensure any current
users of
"new SolrQueryParser" aren't suprised to find the behavior changing
out
from under them -- any future changes for more pluggable query parsers
will probably affect t
: And the default is OR, so we could explicitly set OR in the DMQP
: constructor and rest assured there was no side-effect. Cool?
For DMQP yes -- not for any other plugin writers who have been using
SolrQueryParser up to now.
: Let's not overplan for the future... we already are aware that we'l
On Feb 22, 2007, at 1:58 PM, Chris Hostetter wrote:
: Does DisjunctionMaxQueryParser require the operator to be AND?
Does
: it always need to be set one way or the other? If so, we could just
: override that setting in the constructor, eh?
DisjunctionMaxQueryParser assumes that calling sup
: Does DisjunctionMaxQueryParser require the operator to be AND? Does
: it always need to be set one way or the other? If so, we could just
: override that setting in the constructor, eh?
DisjunctionMaxQueryParser assumes that calling super(schema,defaultField)
will set the schema (for the pur
On Feb 22, 2007, at 1:54 AM, Chris Hostetter wrote:
: I believe now having SolrQueryParser set the operator based on the
: schema configuration is much more sensible.
I haven't looked at this in depth, but i *think* this breaks the
DisMaxQueryParser (i'm guessing AND isn't the default in our te
At 11:30 PM -0800 2/21/07, Ryan McKinley wrote:
>The question is do we want to add *another* parameter to say "don't
>parse the ; sort even if i don't specify the sort parameter"?
>
>Yes, testing the existence/non-existence of a param is not great - but
>I don't think adding another field is worth
> Sigh, sorry about that. ant test is not ant clean test. Will fix presently.
Done.
Anyone think that we should continue maintaing CommonParams? It is
never instantiated. It is possible that it is being used by a custom
request handler out there, somewhere.
thanks!
I'm voting for restru
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[javac] Compiling 171 source files to /tmp/apache-solr-nightly/build
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[
On 2/21/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
Sigh, sorry about that. ant test is not ant clean test. Will fix presently.
Done.
Anyone think that we should continue maintaing CommonParams? It is
never instantiated. It is possible that it is being used by a custom
request handler out t
16 matches
Mail list logo
