Hi
Guys
Apologies.
Has Any body
out on the Form ,have implemented Lucene API in eCommerce ( Search
based Shopping)
Something
similar to http://www.bizrate.com/ .
Please Help
me ???
WITH WARM REGARDS HAVE A NICE DAY [
N.S.KARTHIK]
Hi
Try First Try Using the AnalysisDemo.java code from
http://today.java.net/pub/a/today/2003/07/30/LuceneIntro.html?page=last#thre
ad from java.net for the Contents u seems to experiment with and verify
which analyzer to use.
Probably this will give u some Idea on Analyzers.
with regaards
Hello,
I want to index a 1GB file that contains a list of lines of
approximately 100 characters each, so that i can later get lines
containing some particular text. The natural way of doing it with lucene
would be to create 1 lucene Document per line. It works well except it
is too slow for my
Hello Erik,
Since wilcard queries are not analyzed, how can we deal with accents ?
For instance (in french) a query like ingé* will not match documents
containing
ingénieur but the query inge* will.
Thanks
---
sven
Le jeudi 31 mars 2005 à 17:51:25, vous écriviez :
EH Wildcard terms simply
Hi Karthik,
The e-commerce website www.shoptime.com from Brasil.
William.
From: Karthik N S [EMAIL PROTECTED]
Reply-To: java-user@lucene.apache.org
To: LUCENE java-user@lucene.apache.org
Subject: LUCENE eCommerce
Date: Fri, 1 Apr 2005 14:11:57 +0530
Hi Guys
Apologies.
Has Any
This might sound a bit lame but it has worked for me. I have had the
same problem where the amount of small lucene documents slows down the
building of large indexes.
Search is pretty fast, and read only, so for my case i just created
three indexes and saved every three lucene documents into
On Apr 1, 2005, at 8:09 AM, Sven Duzont wrote:
Since wilcard queries are not analyzed, how can we deal with accents ?
For instance (in french) a query like ingé* will not match documents
containing
ingénieur but the query inge* will.
I presume your analyzer normalized accented characters? Which
On Mar 31, 2005, at 10:49 PM, pashupathinath wrote:
i should do even more analysis as suggested by you
before i should come to a decision of which analyser i
should be using to solve this. what about writing a
custom analyzer to solve this ??? how can i go abt the
logic of implementing this in
EH I presume your analyzer normalized accented characters? Which analyzer
EH is that?
Yes, i'm using a custom analyser for indexing / searching, ti consists
in :
- FrenchStopFilter
- IsoLatinFilter (this is the one that will replace accented
characters)
- LowerCaseFilter
- ApostropheFilter (in
Any ideas on this? I have purchased your book, Lucene in Action, which
is quite good. To make things easier, consider the example on p212. In
item 4, when you combine the queries, what happens you combine them in
and AND fashion? The book only has OR, which works. Although it may
work since
I will soon create some tests for this scenario, but wanted to run this
by the list as well
What performance differences would be seen between a query like this:
a AND b AND c AND d
and this one:
((a AND b) AND c) AND d
In other words, will building a query with nested
On Apr 1, 2005, at 11:07 AM, Sven Duzont wrote:
EH I presume your analyzer normalized accented characters? Which
analyzer
EH is that?
Yes, i'm using a custom analyser for indexing / searching, ti consists
in :
- FrenchStopFilter
- IsoLatinFilter (this is the one that will replace accented
Are there any Lucene extensions that can do simple stemming, i.e. just
for plurals? Or is the only stemming package available Snowball?
Cheers
--
Miles Barr [EMAIL PROTECTED]
Runtime Collective Ltd.
-
To unsubscribe, e-mail:
On Fri, 2005-04-01 at 19:24 +0200, Andrzej Bialecki wrote:
Miles Barr wrote:
Are there any Lucene extensions that can do simple stemming, i.e. just
for plurals? Or is the only stemming package available Snowball?
For which language? Stemming is always language-specific...
If for
On Friday 01 April 2005 18:14, Erik Hatcher wrote:
I will soon create some tests for this scenario, but wanted to run this
by the list as well
Great, see below.
What performance differences would be seen between a query like this:
a AND b AND c AND d
This will use a single
Peter,
Could you provide a straight-forward test case that indexes a few
documents into a RAMDirectory and demonstrates the problem you're
having with AND'd FilteredQuery's?
Give me something concrete and simple and I'll dig into it further.
Erik
On Apr 1, 2005, at 11:13 AM, Kipping,
Paul,
Thanks for your very thorough response. It is very helpful.
For all my projects, I'm using the latest Subversion codebase and
staying current with any changes there, so that is very good news.
Erik
On Apr 1, 2005, at 1:10 PM, Paul Elschot wrote:
On Friday 01 April 2005 18:14, Erik
Hi,
Does Lucene support SpanNear or phrase queries where the clauses or terms
are not of the same field?
If not, could someone let me know which is the way to support proximity
searches with terms belonging to different fields.
Thanks much,
Sujatha Das
I have 5 indexes, each one is 6GB...I need 512MB of Heap size in order to open
the index and have all type of queries. My question is, is it better to just
have on large Index 30GB? will increasing the Heap size increase performance?
can I store an instance of MultiSearcher(OR just Searcher in
On Apr 1, 2005, at 2:29 PM, Sujatha Das wrote:
Hi,
Does Lucene support SpanNear or phrase queries where the clauses or
terms are not of the same field?
If not, could someone let me know which is the way to support
proximity searches with terms belonging to different fields.
No, it does not
: Are there any Lucene extensions that can do simple stemming, i.e. just
: for plurals? Or is the only stemming package available Snowball?
LIA has a case study of jGuru which uses a very specific, home grown
utility method called stripEnglishPlural ... since it's in the case
study chapter,
On Apr 1, 2005, at 7:03 PM, Chris Hostetter wrote:
: Are there any Lucene extensions that can do simple stemming,
i.e. just
: for plurals? Or is the only stemming package available Snowball?
LIA has a case study of jGuru which uses a very specific, home grown
utility method called
Peter's problem intrigued me, so I wrote my own test case using two simple
Filters that filter out all but the first (or last) doc. I seem to be
getting the same results he is, which is certianly. see attached test case.
while this definitely seems like a bug, it also seems like a fairly
23 matches
Mail list logo
