Thanks Erick ,
i understand the issue , but my doubt is when you search for a keyword
which is originally a single word, for example , metacity is really single
keyword . when i search for meta city am not able to get the results , this
is what my doubt ,
if you goto google and search for m
29 okt 2009 kl. 12.12 skrev m.harig:
i've a doubt in search , i've a word in my index welcomelucene
(without
spaces) , when i search for welcome lucene(with a space) , am not
able to
get the hits. It should pick the document welcomelucene.. is there
anyway to
do it ? i've used wildcar
Why would you expect to get a hit on your document? There are
three distinct tokens here:
welcomlucene
welcome
lucene
Lucene searches for *matching* tokens, so searching
for the tokens 'welcome' and 'lucene' essentially asks
"are there two tokens in the document that exactly match
these?" and the
a-user@lucene.apache.org
Sent: Wednesday, March 11, 2009 2:35:02 PM
Subject: Re: search problem when indexed using Field.setOmitTf()
This is expected: phrase searches will not work when you omitTf.
omitTf means positional information about tokens is not saved in
the index.
Span queries & p
27;s more self-descriptive.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
From: Michael McCandless
To: java-user@lucene.apache.org
Sent: Wednesday, March 11, 2009 2:35:02 PM
Subject: Re: search problem when indexed using Field.setOmitTf()
This is
even consider renaming this so it's more self-descriptive.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Michael McCandless
> To: java-user@lucene.apache.org
> Sent: Wednesday, March 11, 2009 2:35:02 PM
> Subject: Re: searc
Siraj Haider wrote:
Yonik Seeley wrote:
On Wed, Mar 11, 2009 at 2:35 PM, Michael McCandless
wrote:
This is expected: phrase searches will not work when you omitTf.
But why would a phrase query be created? The code given looks like
it
should create a boolean query with two terms.
Of
Yonik Seeley wrote:
> On Wed, Mar 11, 2009 at 2:35 PM, Michael McCandless
> wrote:
>
>> This is expected: phrase searches will not work when you omitTf.
>>
>
> But why would a phrase query be created? The code given looks like it
> should create a boolean query with two terms.
>
> Of cour
On Wed, Mar 11, 2009 at 2:35 PM, Michael McCandless
wrote:
> This is expected: phrase searches will not work when you omitTf.
But why would a phrase query be created? The code given looks like it
should create a boolean query with two terms.
Of course, the given code also uses "" as the default
This is expected: phrase searches will not work when you omitTf.
omitTf means positional information about tokens is not saved in the
index. Span queries & phrase queries require that positional
information to work.
Mike
Siraj Haider wrote:
We are having a problem running searches on an
r@lucene.apache.org
Sent: Saturday, January 3, 2009 4:02:52 AM
Subject: Re: Search Problem
Hi again!
I think I may have found the problem but I was wondering if you
could verify:
I have the following for my indexer:
public void add(Document document) {
IndexWriter indexWriter =
IndexWriterF
ument);
}
}
finally
{
commitAndOptimise()
}
HTH
Shashi
- Original Message
From: Amin Mohammed-Coleman
To: java-user@lucene.apache.org
Sent: Saturday, January 3, 2009 4:02:52 AM
Subject: Re: Search Problem
Hi again!
I think I may have found the problem but I was wondering if you
co
eader for
example
{
indexWriter.addDocument(document);
}
}
finally
{
commitAndOptimise()
}
HTH
Shashi
- Original Message
From: Amin Mohammed-Coleman
To: java-user@lucene.apache.org
Sent: Saturday, January 3, 2009 4:02:52 AM
Subject: Re: Search Problem
Hi ag
To: java-user@lucene.apache.org
Sent: Saturday, January 3, 2009 4:02:52 AM
Subject: Re: Search Problem
Hi again!
I think I may have found the problem but I was wondering if you
could verify:
I have the following for my indexer:
public void add(Document document) {
IndexWrit
iginal Message
From: Amin Mohammed-Coleman
To: java-user@lucene.apache.org
Sent: Saturday, January 3, 2009 4:02:52 AM
Subject: Re: Search Problem
Hi again!
I think I may have found the problem but I was wondering if you
could verify:
I have the following for my indexer:
public void add(Doc
user@lucene.apache.org
Sent: Saturday, January 3, 2009 4:02:52 AM
Subject: Re: Search Problem
Hi again!
I think I may have found the problem but I was wondering if you
could verify:
I have the following for my indexer:
public void add(Document document) {
IndexWriter indexWr
ashi
- Original Message
From: Amin Mohammed-Coleman
To: java-user@lucene.apache.org
Sent: Saturday, January 3, 2009 4:02:52 AM
Subject: Re: Search Problem
Hi again!
I think I may have found the problem but I was wondering if you could verify:
I have the following for my indexer:
pu
Hi again!
I think I may have found the problem but I was wondering if you could
verify:
I have the following for my indexer:
public void add(Document document) {
IndexWriter indexWriter =
IndexWriterFactory.createIndexWriter(getDirectory(), getAnalyzer());
try {
AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
Well, your query results are consistent with what Luke is
reporting. So I'd go back and test your assumptions. I
suspect that you're not indexing what you think you are.
For your test document, I'd just print out what you're indexing
and the field it's going into. *for each field*. that is, every
Hi Erick
Thanks for your reply.
I have used luke to inspect the document and I am some what confused.
For example when I view the index using the overview tab of Luke I get
the following:
1 bodytest
1 id 1234
1 namertfDocumentToIndex.rtf
1 pathrtfD
Casing is usually handled by the analyzer. Since you construct
the term query programmatically, it doesn't go through
any analyzers, thus is not converted into lower case for
searching as was done automatically for you when you
indexed using StandardAnalyzer.
As for why you aren't getting hits, it
Hi
I have tried this and it doesn't work. I don't understand why using
"amin" instead of "Amin" would work, is it not case insensitive?
I tried "test" for field "body" and this works. Any other terms don't
work for example:
"document"
"indexed"
these are tokens that were extracted when
Basically Lucene stores analyzed tokens, and looks up for the matches based
on the tokens.
"Amin" after StandardAnalyzer is "amin", so you need to use new Term("body",
"amin"), instead of new Term("body", "Amin"), to search.
--
Chris Lu
-
Instant Scalable Full-Text Search
AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
AUTOMATIC REPLY
LUX is closed until 5th January 2009
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
Hi
Sorry I was using the StandardAnalyzer in this instance.
Cheers
On 2 Jan 2009, at 00:55, Chris Lu wrote:
You need to let us know the analyzer you are using.
--
Chris Lu
-
Instant Scalable Full-Text Search On Any Database/Application
site: http://www.dbsight.net
You need to let us know the analyzer you are using.
--
Chris Lu
-
Instant Scalable Full-Text Search On Any Database/Application
site: http://www.dbsight.net
demo: http://search.dbsight.com
Lucene Database Search in 3 minutes:
http://wiki.dbsight.com/index.php?title=Create_L
D'oh!
Of course - I'm using StandardAnalyzer. Changing to a
PerFieldAnalyzerWrapper with a KeywordAnalyzer for
that field fixes the issue.
Thanks so much for fast response.
Ulf
--- Ian Lea <[EMAIL PROTECTED]> wrote:
> Hi
>
>
> I bet you are using an analyzer that is downcasing
> isbn:00714
Hi
I bet you are using an analyzer that is downcasing isbn:007149216X to
isbn:007149216x. I've been there! Options include creating the query
programmatically, using PerFieldAnalyzerWrapper, downcasing everything
yourself in advance. Or convert to ISBN-13.
--
Ian.
On Fri, May 16, 2008 at 10
John Powers wrote:
Lucene 1.4 is what I use for the application and how I compile things
But in the help/about it says "null"
And I usually use the webstart, ya. But I've tried from a downloaded
jar as well. and I'm using java1.6 from sun
Ah, all is clear now. Luke will not work with Lucene <
lto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 4:22 PM
To: java-user@lucene.apache.org
Subject: Re: search problem/odd results
John Powers wrote:
> java.lang.NoSuchFieldException: IMPL
> at java.lang.Class.getDeclaredField(Unknown Source)
That's a strange one ... Which
John Powers wrote:
java.lang.NoSuchFieldException: IMPL
at java.lang.Class.getDeclaredField(Unknown Source)
That's a strange one ... Which version of Lucene are you using with Luke
(you can check this in Help -> About box, look for "Lucene version:").
Are you running this from Java We
)
at java.awt.EventDispatchThread.run(Unknown Source)
IMPL
-Original Message-
From: Daniel Naber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 3:27 PM
To: java-user@lucene.apache.org
Subject: Re: search problem/odd results
On Wednesday 09 May 2007 16:17, John Powers wrote
On Wednesday 09 May 2007 16:17, John Powers wrote:
> Yes, it doesn't work. it gives an error modal dialog box that says
> "IMPL".
Is there a more useful error message when you start Luke from the command
line and try to open the index?
Regards
Daniel
--
http://www.danielnaber.de
---
Yes, it doesn't work. it gives an error modal dialog box that says
"IMPL".
-Original Message-
From: Daniel Naber [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 4:45 PM
To: java-user@lucene.apache.org
Subject: Re: search problem/odd results
On Tuesday 08 May 2
On Tuesday 08 May 2007 23:42, John Powers wrote:
> I've had problems with luke in the past not being able to read the
> files.
Just make sure you specify the directory, not the files when opening an
index with Luke. Also use the latest version (0.7).
Regards
Daniel
--
http://www.danielnaber
completely, that'd be fine. but it returns two.. why those
two?That's the part I'm not getting.
Thanks for your response...
-Original Message-
From: Erick Erickson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 1:47 PM
To: java-user@lucene.apache.org
Subject: Re:
First question: What analyzers are you using at index and search time?
Second question: Have you tried using query.toString() to see how
the query parses? If so, you should post the results.
Third question: Have you used Luke to examine your index, to see
what's actually in there (which may surp
Thanks Erick.
On 10/27/06, Erick Erickson <[EMAIL PROTECTED]> wrote:
I'm not all that familiar with the remotesearcher stuff. But somewhere you
must open an indexreader. So wherever that code is, just close the index
reader (and anything that uses it, like Serachables(?)) and re-open it.
That
s
I'm not all that familiar with the remotesearcher stuff. But somewhere you
must open an indexreader. So wherever that code is, just close the index
reader (and anything that uses it, like Serachables(?)) and re-open it. That
should pick up your recent changes.
Of course, now would be a fine time
Thanks Erick for the information.
Actually I am using RemoteParallelMultiSearcher with 10 Search Servers, my
crawler program freequently add new documents in to all the Search Servers
in a distributed manner. So in this case, if I add a document in a
particular index, I need to restart the search
Yes, but you must close and re-open your SEARCHER. There are various schemes
for doing this based upon now expensive it is to open a new searcher and how
often you need to do it, but it's not built into Lucene AFAIK. It all
depends upon how quickly you have to see the results of your update.
Also
I guess that fixes the problem.
Thanx
--
View this message in context:
http://www.nabble.com/search-problem-t1506294.html#a4096490
Sent from the Lucene - Java Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTE
: Problem: while there is a hit, only the timestamp and ip of the very first
: line in the logfile are shown, but not the "matching" ip and timestamp later
: in the logfile. Any suggestions how to get to the "right entries" ?
It sounds like you are creating one Document per logfile, and then usin
25 apr 2006 kl. 17.54 skrev April06:
We indexed several logfiles which contain for example a timestamp,
an ip and
additional information (all defined as a field) all in one line.
A logfile itself contains many of these lines.
We used a BooleanQuery (timestamp / ip) to search for a ip betwe
: Where can I see the example using HitCollector ?
if you mean examples of writing a HitCollector, then the javadocs for the
HitCollector class are a good place to start. As is the source code for
TopDocCollector and and TopFieldDocCollector.
If you mean an example of using a HitCollector when
2) assuming what you want is not all brands and all prices, but just the
prices and brands of the documents in you results, then i would strongly
recommend doing your search twice -- once do get the Hits object you need
and once using a HitCollector. Within the HitCollector, use FieldCaches
to lo
: price and about 10 more additional fields. I want to not just find
: something in the index also I want to get the lists of all brands and
: price. The list of brands is needed for displaying all of the products
: and the quantity of products of this brand for certain search request.
1) iterati
Anton Potehin wrote:
I have a problem.
There is an index, which contains about 6,000,000 records (15,000,000
will be soon) the size is 4GB. Index is optimized and consists of only
one segment. This index stores the products. Each product has brand,
price and about 10 more additional fields. I
try to use mime format just as "application/pdf" and to see if it is feasible
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Lucene is case sensitive. Make sure the case in your query matches the case
in the index. You could also try selecting the keyword analyser in Luke.
I've done both, but the results are as written.
Dirk
-
To unsubscribe, e-m
Lucene is case sensitive. Make sure the case in your query matches the case
in the index. You could also try selecting the keyword analyser in Luke.
Paul I.
Dirk Hennig
Hi Pierrick,
It is very likely that the analyzer bound to your query parser filters
"pdf" out, maybe because it has only 3 letters,
Luke shows me "filetype:pdf" as parsed and rewritten query.
I think than this can't be the problem or am I wrong on this?
Greetings,
Dirk
Hi,
Dirk Hennig wrote:
Even the simple query "+filetype:pdf" returns no results. But
"+filetype:html" works perfect.
How can this be? Has anyone an idea?
It is very likely that the analyzer bound to your query parser filters
"pdf" out, maybe because it has only 3 letters,
Cheers,
--
Pier
56 matches
Mail list logo
