Hi
I am having problems with searching for special charecters like %,*,+,- etc.
I am using standard analyzer. I create queries using the query constructor.
I read in the forums and tried with QueryParser.escpae and parse methods,
but the problem is if I have two fields as "ABC+S" and "ABC-S" and
Hello, I am indexing documents with a field that contains the first and
last name of people. It is working wonderfully with a slight issue: if
Thomas is indexed for a document, I would like searches for Tom to match
that document. I am sure this is a common problem that many of you must have
addre
There is not much impact as long as you turn off Norms for the
majority of them.
- Mark
On Dec 2, 2008, at 8:47 AM, Darren Govoni <[EMAIL PROTECTED]> wrote:
Hi,
I saw this question asked before without a clear answer. Pardons if I
missed it in the archive elsewhere.
Is there a serious deg
: > "foo AND (
: > groupboost_A:dummy^10 OR
: > groupboost_B:dummy OR
: > groupboost_C:dummy^0.1 OR
: > ...
: > groupboost_Z:dummy
: > )"
: >
: > With that query, it seems that only documents matching foo will result
: > in a hit and be scored?
:
: Someone else than me needs to answer this.
Hi everybody:
I have seen the lucene project for C++ has been abandoned, could you tell me
if there is another similar implementation of java lucene in C++ ???
With ConcurrentMergeScheduler, adding all indexes at once to a single
IndexWriter will use multiple threads to do the merging, assuming you
have enough total segments that need merging (> 2 X mergeFactor will
use 2 threads; > 3 X mergeFactor will use 3, etc.; CMS defaults to max
3 merge t
Our experience is, if the number of cores equal number of active
threads, then it performs optimal using single JVM.
Both on Windows XP and CentOS 5.2, with Lucene 2.3.2
Sincerely,
Sithu D Sudarsan
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-Original Message-
From: Glen Newton [mailto:[EMAIL
elguillelmo wrote:
Kai_testing Middleton wrote:
The nutch analyzer is NutchDocumentAnalyzer. Does anyone know how to add
this to the Luke classpath? I tried this kind of thing but it didn't work
I'm trying to work out the same thing, to no avail. Would anybody be able to
detail how to add
Let's say I have 8 indexes on a 4 core system and I want to merge them
(inside a single vm instance).
Is it better to do a single merge of all 8, or to in parallel threads
merge in pairs, until there is only a single index left? I guess the
question involves how multi-threaded merging is and if it
Kai_testing Middleton wrote:
>
> The nutch analyzer is NutchDocumentAnalyzer. Does anyone know how to add
> this to the Luke classpath? I tried this kind of thing but it didn't work
>
I'm trying to work out the same thing, to no avail. Would anybody be able to
detail how to add Nutch's Analy
Hi Ian
Thanks for the suggestion. I was able to write the custom analyzer to return
non-letters as tokens, as well as to keep the numeric characters instead of
skipping them.
This is probably not the best solution, but at least i can have a demo
without bugs :-)
To save time for others who may ha
I prefer Externalizable as well as it makes Serialization faster. Perhaps
also for Query and it's subclasses to start? I had code to do this for
Analyzer as well which could be useful, perhaps a different patch though.
On Tue, Dec 2, 2008 at 2:22 AM, Michael McCandless <
[EMAIL PROTECTED]> wrote
Hi,
I saw this question asked before without a clear answer. Pardons if I
missed it in the archive elsewhere.
Is there a serious degradation of performance when using high number of
fields per document? Like 100's? Is the impact more on the write than
the read?
What are the performance charact
Karl Wettin wrote:
As for statically setting a serialVersionUID in the class, one could
instead set it to a final value and implement Externalizable in
order to keep binary compatibility between class versions that
contains more changes than what the Serializable reflection support
code
Jason Rutherglen wrote:
Hi Mike,
Can you build and release a 2.4 jar using the 2.3 build environment?
I don't think that's the right approach here. We should, instead,
directly fix Term.java to be serializable, if that's the goal.
(Or, as a workaround, Karl's suggestion that you build y
This is the exception:
Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.lucene.document.Document.add(Lorg/apache/lucene/document/Field;)V
at
org.pdfbox.searchengine.lucene.LucenePDFDocument.addUnindexedField(LucenePDFDocument.java:224)
at
org.pdfbox.searchengine.lucene.Lucene
Thanks, I clearly understood it.
Grant Ingersoll-6 wrote:
>
> Possibly, but probably not. Index time boosting is generally done to
> say one field is more important than another field, or one document is
> more important than another document, whereas query time boosting
> generally says
17 matches
Mail list logo
