Hi:
when i post XML file to solr,data is indexed but if after a week or two i
again post the same file to solr i usually get this error "The remote server
returned an error: (500) Internal Server Error."
i dont know what is the problem.
if i create a new instance of solr and place "solr.config"
: thanks for the answer, with that information I can pull out the term
: frequency. Reason for all this, is that we want to use this scoring
: algorithm:
: http://download-uk.oracle.com/docs/cd/B19306_01/text.102/b14218/ascore.htm
Uh why? Based on the description this sounds exactly like
> sure, but what logic would you suggest be used to decide when to make them
> optional? :)
Operationally, I was thinking a tokenizer could use the stop-word list
(or an optional-word list) to mark tokens as optional rather than
removing them from the token stream. DisMaxOptional would then
gene
On 27-Mar-08, at 1:46 AM, Koji Sekiguchi wrote:
Hello,
If an index has (many) deleted docs and not optimized,
when I set hl.requireFieldMatch=true, highlight doesn't work
sometimes.
cause:
If hl.requireFieldMatch set to true,
DefaultSolrHighlight.getQueryScorer()
uses QueryScorer(Query,I
> We use two fields, one with and one without stopwords. The exact
> field has a higher boost than the other. That works pretty well.
Thanks for the tip, wunder! We are doing likewise for our pf parm of
DisMax and that part works well -- exact matches are highly relevant
and stopped-matches less
Thanks all, for the answers
On Thu, Mar 27, 2008 at 10:04 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 4:56 PM, Otis Gospodnetic
> <[EMAIL PROTECTED]> wrote:
> > Or use the JNDI approach that's described on the Wiki. I've used it
> with Jetty and it works nicely. Multip
If you have "doors" in your index and a person enters: "the doors", why not
just drop stop-words at query time?
If a person searches for "music by the doors" and you have "music doors" in the
index and really uses quotes to get the exact phrase, you can try it like Hoss
said, and retry without s
On Thu, Mar 27, 2008 at 4:56 PM, Otis Gospodnetic
<[EMAIL PROTECTED]> wrote:
> Or use the JNDI approach that's described on the Wiki. I've used it with
> Jetty and it works nicely. Multiple webapp contexts, multiple Solr indices,
> but a single JVM.
With multiple smaller collections, one might
For a field to be searchable it has to be indexed (and not just stored).
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Vinci <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Thursday, March 27, 2008 4:43:02 AM
Subject: Re: document
Or use the JNDI approach that's described on the Wiki. I've used it with Jetty
and it works nicely. Multiple webapp contexts, multiple Solr indices, but a
single JVM.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Yonik Seeley <[EMAIL PROTE
On Thu, Mar 27, 2008 at 3:47 PM, tim robertson
<[EMAIL PROTECTED]> wrote:
> Would I be correct in thinking that for each schema I want, I need a new
> SOLR instance running?
For different search collections, it's generally best to run a
separate Solr instance.
If you need to run multiple in the
tim robertson wrote:
Hi,
Would I be correct in thinking that for each schema I want, I need a new
SOLR instance running?
Hey Tim,
Documents aren't required to have all of the fields (it's not a
database), so what I would do is just have all of the field definitions
in a single schema.xml fil
Today I added a single 9gig tab file into solr, with the resulting index
being 16gig.3 hours to load and is performing mightily fine (jvm -Xmx3G)
On Thu, Mar 27, 2008 at 7:08 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 1:21 PM, Andrew Tan <[EMAIL PROTECTED]>
> wrote:
>
Hi,
Would I be correct in thinking that for each schema I want, I need a new
SOLR instance running?
Thanks
Tim
On Thu, Mar 27, 2008 at 1:21 PM, Andrew Tan <[EMAIL PROTECTED]> wrote:
> I am new to solr and just try it out. I copied solr.war (from 1.2.0
> distribution) into tomcat 5.5.26's webapps directory and started tomcat.
> Then I use the java SimplePostTool to add documents. when the document
> is s
Hi ,
I am new to solr and just try it out. I copied solr.war (from 1.2.0
distribution) into tomcat 5.5.26's webapps directory and started tomcat.
Then I use the java SimplePostTool to add documents. when the document
is small, things are fine. However, when I tried to add document
(greater than
: Is there any way to get the logs to stderr/stdout to be in 24hour time?
http://wiki.apache.org/solr/FAQ#head-ffe035452f21ffdb4e4658c2f8f6553bd6ca
"How do I change the logging levels/files/format ?"
-Hoss
Hi,
thanks for the answer, with that information I can pull out the term frequency.
Reason for all this, is that we want to use this scoring algorithm:
http://download-uk.oracle.com/docs/cd/B19306_01/text.102/b14218/ascore.htm
but is there a performance cost on the explain, that can be painfull
Is there any way to get the logs to stderr/stdout to be in 24hour time?
Thanks.
Doug
Hello,
If an index has (many) deleted docs and not optimized,
when I set hl.requireFieldMatch=true, highlight doesn't work sometimes.
cause:
If hl.requireFieldMatch set to true, DefaultSolrHighlight.getQueryScorer()
uses QueryScorer(Query,IndexReader,String) constructor in Lucene
highlighter.
The
Hi hossman,
Thank you for your reply, question for the searchable field: Am I declare
the field to be indexed in schema is enough to make it searchable? (Assume I
write my schema based on the default one)
Thank you,
Vinci
hossman wrote:
>
>
> : 1. Can I limit the number of returned document i
: 1. Does Solr have a limit, e.g a % or a number to limit the number of
: document involved in sorting? or just sort all document?
it depends on the context of your question ... if you use any existing
fieldtypes, then standard LUcnee sorting kicks in, and a Fieldcache is
built containing the v
: frequently get queried for "The Doors". Articles and prepositions
: (the stuff of good stop-lists) seem to me to be in a fuzzier class --
: use 'em if you have 'em during matching, but don't kill your queries
: because of them. Hence some desire to make them in some way
: "optional" during mat
23 matches
Mail list logo