Daniel Noll wrote:
On Tuesday 15 May 2007 21:59:31 Narednra Singh Panwar wrote:
try using -Xmx option with your Application. and specify maximum/ minimum
memory for your Application.
It's funny how a lot of people instantly suggest this. What if it isn't
possible? There was a situation a wh
I am currently exploring how to solve performance problems I encounter with
Lucene document reads.
We have amongst other fields one field (default) storing all searchable
fields. This field can become of considerable size since we are indexing
documents and store the content for display within
If you enter a.b.c.d.e.f.g.h to that demo you'll see that
the demo simply breaks the input text on '.' - that has
nothing to do with filenames.
Arnold Leung <[EMAIL PROTECTED]> wrote on 16/05/2007 22:38:41:
> Does Snowball (English) support "filenames?"
>
> ex. Authenicate.dll does not return a "
Does Snowball (English) support "filenames?"
ex. Authenicate.dll does not return a "hit" if the keyword
"authenticate" (without ".dll") is used.
("authenticate*" or authenticate.dll works though)
Is there anyway to get around this? How come the Snowball demo
(http://snowball.tartarus.org/
On Thursday 17 May 2007 09:50:55 Erick Erickson wrote:
> I thought that that's the point in the Synonym injection
> example, setting Term.setPositionIncrement(0) for the injected
> token(s). That way. phrase queries work since all of the
> injected tokens share the same offset
>
> But I've been
There are quite a few ways to do this...you just read in the file to
create a list of the words and when your query parser sees the right
keyword either use a TokenFilter that expands to each word or just add
each word to a BooleanQuery as a Should clause (or expand to a proper
Lucene syntax st
<>
I thought that that's the point in the Synonym injection
example, setting Term.setPositionIncrement(0) for the injected
token(s). That way. phrase queries work since all of the
injected tokens share the same offset
But I've been wrong before.
Erick
On 5/16/07, Daniel Noll <[EMAIL PROTEC
On Wednesday 16 May 2007 23:50:55 Erick Erickson wrote:
> That's interesting. I suppose you could add the "synonym" of
> WildAnimals$ whenever you encountered any of the items in your
> list, then when concept searching is called for, search on
> WildAnimals$.
>
> Highlighting might be tricky, but
Pilot error... I had a cut & paste error and was indexing "C D" as the
document I said I was indexing as "D". Sorry about that.
Thanks, david.
On 5/16/07, Doron Cohen <[EMAIL PROTECTED]> wrote:
> Query Parsed As Matches Matches
> - -
I noticed in previous discussion about some index integrity detection
classes that were around in version 1.4 (NoOpDirectory or
NullDirectory). Does anyone know if this in the 2.1.0 release? I didn't
see in 2.1.0 or the contrib folders.
Brian Beard
[Moving the discussion from java-dav to java-user]
Hi Terry,
The index I suggested would be in addition to the one you now have, so
the requirements you mentioned would not be affected (unless of course
you have a single-index requirement :) ).
Given the narrow use for this additional index, you
> Query Parsed As Matches Matches
> - - ---
> NOT B -body:B 2, 4
> *:* NOT B MatchAllDocsQuery -body:B 2, 4 2, 4, 5
> *.* AND NOT B +MatchAllDocsQuery -body:B 2, 4 2, 4, 5
: 5 B
: Expected Actual
: Query Parsed As Matches Matches
: - - ---
: NOT B -body:B 2, 4
: *:* NOT B MatchAllDocsQuery -body:B 2, 4
Hi!
Could you please upload the 2.1 version of lucene core and analyzers to the
maven2 repository?
See:
http://jira.codehaus.org/browse/MAVENUPLOAD-1541?page=com.atlassian.jira.plu
gin.system.issuetabpanels:all-tabpanel
I tried to do it myself, but they wouldn't let me. Thanks a lot!
Regards,
Hi all,
I know this whole distinct query has been discussed a bunch of times for
various scenarios because I've been scouring the forums trying to find a
clue as to how I could solve my problem. I'm indexing a large set of
parent-child term relations (~1 million). The number of unique terms is
ab
I see my tables didn't come through so well. Here's (I hope) a plain
text version:
I understand that it would be best to have a UI that mapped lists of
terms to MUST, MUST_NOT and SHOULD, but I'm currently constrained to
using the QueryParser with boolean operators.
Given that, I was thinking th
I understand that it would be best to have a UI that mapped lists of terms
to MUST, MUST_NOT and SHOULD, but I'm currently constrained to using the
QueryParser with boolean operators.
Given that, I was thinking that the addition of "*:*" (in 2.1) to represent
MatchAllDocsQuery might help solve:
That's not precisely what I was imagining, although it does sound viable
- I was thinking of using standard indexing, and then generating concept
instantiations ("synonyms") at query time. - Steve
Erick Erickson wrote:
> That's interesting. I suppose you could add the "synonym" of
> WildAnimals$ w
That's interesting. I suppose you could add the "synonym" of
WildAnimals$ whenever you encountered any of the items in your
list, then when concept searching is called for, search on
WildAnimals$.
Highlighting might be tricky, but certainly do-able, especially with
the capabilities of a MemoryInd
Hi Charles,
The need presented by your use case sounds very similar to that served
by the SynonymAnalyzer given in Erik Hatcher's and Otis Gospodnetic's
excellent book "Lucene in Action" - take a look:
http://lucenebook.com/
Steve
Charles Patridge wrote:
> I have looked around on Lucene w
While I too am still learning, I ran into this last week.
Try this:
String line = "justin";
Query query = parser.parse(line);
TermQuery tq = new TermQuery(new Term("category", "Pop"));
Filter qf = new QueryFilter(tq);
Hits hits = search(query, qf);
HTH,
Wayne
Anna Putnam wrote:
> Hi all,
>
21 matches
Mail list logo
