Hi all,
thank you for your reply. The id's that we send are unique, so we still have no
clue what is happening :)
greetings,
Tim
-Oorspronkelijk bericht-
Van: Mike Klaas [mailto:[EMAIL PROTECTED]
Verzonden: za 26-4-2008 1:52
Aan: solr-user@lucene.apache.org
Onderwerp: Re: Delete's
I'm using 1.2 and things are fine for the most part except for an occasional
problem.
When returning a highlighted version of the results the output from solr is
truncated. In most cases the whole of the field (called content) is
returned highlighted correctly. For example with this query in the
I'm searching using query of 'food' and get back 572 results. When I do a
search for 'food drink' I am expecting more results since it's defaulting to
ORing the search terms, however, I now get back 6 results. I'm sure I'm
doing something stupid, but I don't know what for sure. I am using a
check for
solrQueryParser defaultOperator=OR/
in schema.xml
On Apr 28, 2008, at 12:16 PM, briand wrote:
I'm searching using query of 'food' and get back 572 results. When
I do a
search for 'food drink' I am expecting more results since it's
defaulting to
ORing the search terms,
It was set to AND as the default so I changed it to
solrQueryParser defaultOperator=OR/
restarted SOLR but still seeing the same results. The debug output looks
the same as well.
Alok K. Dhir wrote:
check for
solrQueryParser defaultOperator=OR/
in schema.xml
On Apr 28,
I don't think the defaultOperator applies to Dismax in the same way as the
Standard Request Handler. The Dismax handler uses the mm (Minimum 'Should'
Match) parameter to specify how many words should match the query. You
may need to change this to get it working the way you want it.
: It is working, but I disabled recursive field aliasing. Two questions:
:
: * Is it possible to do recursive field aliasing from solrconfig.xml?
: * If not, do we want to preserve this speculative feature?
:
: I think the answers are no and no, but I'd like a second opinion.
the recursive
: I am frustrated that I have to pick between the two because I want both. The
: way I look at it, there should be a more configurable query handler which
: allows me to dimax if I want to, and pick a parser for the user's query
: (like the flexible one used by the standard query handler, or the
I'm already aware of defType but that doesn't really change things.
Either I use defType of DISMAX to get DisjunctionMaxQuery but then I can't
use prefix queries and more complicated boolean queries, OR I use the
standard defType which doesn't use DisjunctionMaxQuery.
I need this feature ASAP
On Apr 27, 2008, at 7:50 AM, Thijs Vonk wrote:
What is the best way to get the unique terms from a field in a result?
I've been using SimpleFacet to do this. However, I don't need the
counts, so it seems overkill to have to iterate over all the result
documents per field to get the unique
I'm already aware of defType but that doesn't really change things.
Either I use defType of DISMAX to get DisjunctionMaxQuery but then I can't
use prefix queries and more complicated boolean queries, OR I use the
standard defType which doesn't use DisjunctionMaxQuery.
I need this feature ASAP
On 4/28/08 10:20 AM, Chris Hostetter [EMAIL PROTECTED] wrote:
the recursive mapping was something i put in the DismaxQueryParser because
it was easy. The param syntax of the DismaxRequestHandler has never
supported it, but it's possible someone out there has a subclass that
takes advantage
In 1.3 (trunk, dev build), the query parsing has been extracted into a
component. It shoudl be easy to replace just query parsing component
and keep the rest of the chain the same.
I'm not quite following why it is a problem to have two urls for
dismax vs standard query. Dismax expects
: Either I use defType of DISMAX to get DisjunctionMaxQuery but then I can't
: use prefix queries and more complicated boolean queries, OR I use the
: standard defType which doesn't use DisjunctionMaxQuery.
I think I missunderstood your complaint ... it sounds like you don't care
about (or
Yep setting mm=1 did the trick for us. Thanks!
Howard Lee-2 wrote:
I don't think the defaultOperator applies to Dismax in the same way as the
Standard Request Handler. The Dismax handler uses the mm (Minimum 'Should'
Match) parameter to specify how many words should match the query. You
I'm looking at the latest source and I see that the only way I can use
Lucene's DisjunctionMaxQuery is to use the limited query syntax. These two
are entangled together in SolrPluginUtils.DisjunctionMaxQueryParser. Am I
looking at the wrong place? I'd love to be proven wrong.
We want our
Now you've got it Hossman.
I don't plan on mucking with the parser syntax. I look at this feature as a
smarter default field. Instead of it being one field, it is an array of
them constructed via Dismax with various boosts.
~ David
hossman wrote:
: Either I use defType of DISMAX to get
You are correct I'm looking for the unique values for one field in a
DocSet. The field is not multivalued. and it contains only 1 long value,
the pk of a database table
But you said the counts are stored in the index, I don't see that.
Because when I debug simplefacet. It always iterates over
I'm using the synonyms text file such that when you enter travel you find all
things related to vacation. However, when I enter in travelling it does
not find anything related to vacation, I assume it's because I'm not
explicitly putting travelling in the synonyms file. Is there a way to
: 1. I use the following URL to successfully browse to the Admin interface of
: one of the cores:
:
: http://devbox:8080/solr/solrtest/admin/
:
: 2. On the resulting page, I click on the link [SCHEMA]
:
: 3. This results in a 404 error. The link to this page is
:
: You are correct I'm looking for the unique values for one field in a DocSet.
: The field is not multivalued. and it contains only 1 long value, the pk of a
: database table
: But you said the counts are stored in the index, I don't see that. Because
there's something very confusing about your
: A while back Hoss described Solr queuing behavior:
:
: searches can go on happily while commits/adds are happening, and
: multiple adds can happen in parallel, ... but all adds block while a
: commit is taking place. i just give all of clients that update the
: index a really large timeout
: Suppose I commit a number of adds but the adds have caused a lengthy segment
: merge and the commit blocks and times out. How can I tell when all my adds are
: searchable? Do I have to query solr for the given collid field value for each
: document the users document list view?
When HTTP
23 matches
Mail list logo
