Hi,
yesterday I tried the Solr-1.3-RC2 and everything seems to work fine using the
traditional single-core setup. But while troubleshooting the new multi-core
feature, I realized for the first time, that I have been using the deprecated
(even in 1.2) class SolrServlet. This is a huge problem
but Mick Semb Wever will be taking over this job for the next two weeks.
back from holidays and taking over where Glenn-Erik left. i'm very new
to Solr so please bear with me,
i'll run through our setup from scratch.
Our test list has 9 entries:
abcd efgh ijkl, abcd efgh, efgh ijkl, abcd,
Trying to build a simple UpdateRequestProcessor that keeps a field
(the time of original index) when overwriting a document.
1) Can I make a updateRequestProcessor chain only work as a certain
handler or does putting the following in my solrconfig.xml:
updateRequestProcessorChain
Answered my own qs, I think:
Trying to build a simple UpdateRequestProcessor that keeps a field
(the time of original index) when overwriting a document.
1) Can I make a updateRequestProcessor chain only work as a certain
handler or does putting the following in my solrconfig.xml:
: When using the MoreLikeThisHandler with facets turned on, the facets show
: counts of things that are more like my original document. When I use the
: MoreLikeThisComponent, the facets show counts of things that match my
: original document (I'm querying by document ID), so there is only one
: I have a multivalued field that I would want to score individually for each
: value. Is there an easy way to do that?
Lucene-Java has a (somewhat new) feature called Payloads which allows
for things like this built arround the idea that when indexing, any Token
cn contain an arbitrary data
: I ran into the same problem some time ago, couldn't find any relation to the
: boost values on the multivalued field and the search results. Does anybody
as the OP mentioned, the index time boost values for a field are per field
*name* not per value ... they all get folded in together into
: I see two solutions:
:
: Either put all possible endings in the synonym file - I do not really
: like this solution, as it would make the file very large, and it also
: is too easy to miss some specific ending. Or run the stemmer before
: the synonym filter, in which case the synonym
: And then calls to /update2 will go through the chain. Calls to /update will
: not.
Correct. Note also that there is also a default attribute you can put
on one UpdateProcesserChain and then XmlUpdateRequestHandler (etc...) will use
that even if you don't tell them to use a particular chain.
: Any ideas on how could we register single request handler for handling
: multiple (wildcarded) contexts/resource uri's ?
:
: (something like) :
:
: requestHandler name=/app/* class=solr.StandardRequestHandler
: requestHandler name=/app/*/query class=solr.StandardRequestHandler
One of the
: 1. Using the compound file format drops the number of file descriptors
: needed. Any other benefits?
not that i know of.
: 2. Indexing may be slower. What about query performance?
If i remember correctly it's a little slower, but a little may be
inconsequential.
: 3. Since Lucene 1.4, the
On Sun, Sep 7, 2008 at 11:00 AM, Chris Hostetter
[EMAIL PROTECTED]wrote:
inform, no ... but the factories should be getting instantiated during
SolrCore init, what makes you think it's not until first use? (that would
be a bug if it's true, but a quick skim of SolrCore suggests it should be
On Sun, Sep 7, 2008 at 11:21 AM, Chris Hostetter
[EMAIL PROTECTED]wrote:
SolrIndexConfig.java shows useCompoundFile = true as the defualt ... are
you seeing something different getting used as the default somewhere?
The example solrconfig.xml has useCompoundFile as false both in the
13 matches
Mail list logo
