On Saturday 15 April 2006 03:36, Jeryl Cook wrote:
>
> Im the co-worker who suggested to Ananth( I've think we have been debating
> this for 3 days now,from the post it seems he is winning :)... )
>
> Anway, as Ananth stated I suggested this because I am wondering if lucene
> could solve a bottl
Im the co-worker who suggested to Ananth( I've think we have been debating
this for 3 days now,from the post it seems he is winning :)... )
Anway, as Ananth stated I suggested this because I am wondering if lucene
could solve a bottle neck query that is taking a deathly long time to
complete(rea
Gentlemen,
A join like operation between Lucene indexes can be done with
(at least) reasonable performance by using a few standard
methods from RDB's: sort before going to disk, and cache
whenever possible. The steps are:
- query the first Lucene index with the low level search API to get the
Lu
Erick,
Don't get me wrong. I agree with you 100 percent on everything you just
said, and have been advocating what you are saying. I turned to the forum to
get other peoples thoughts on the issue, feeling that my perspective may be
a little warped, and wanted to see what the community thinks. I thi
On 4/13/06, Ananth T. Sarathy <[EMAIL PROTECTED]> wrote:
>
> No we do have drop downs selects that would allow for the substitution,
> but
> we also have a free text fields to allow the user to search. That solution
> would I think work for the DB query replacement, but you would need a
> regular n
Depending on what you are trying to search. Let's say your table A is
the table with the "real" content, and B and C are your lookup table.
You should build one index in this case. And select A's content
together with B and C's lookup value into the documents.
I strongly recommend you take a look
: Also we need to address the Join Between A and B and C, which I don't know
: see how with out taking out values out of the hit list.
When discussing Index structure strategies, speaking in generalities like
A B and C is hard .. because there is no 100% generaic solution about how
to "join" X an
No we do have drop downs selects that would allow for the substitution, but
we also have a free text fields to allow the user to search. That solution
would I think work for the DB query replacement, but you would need a
regular non underscored field to allow for free text.
On 4/13/06, Erick Erick
Well, that's a problem you must already be solving. Somewhere, you have to
construct your DB query and recognize what constitutes a "term". From your
previous mail, you imply you can construct this query...
select count(distinct Crew_ID) from Crew_TItles where Title="Producer"
Where did you get "
Hi,
> From: Ananth T. Sarathy [mailto:[EMAIL PROTECTED]
>
> How would a second index solve the 1:N relationship issue?
> For the record I agree that Lucene is Document Centric.
Why Lucene should solve this problem? What is your search document?
Or what is your search result? What are you goin
How would that work is some on a form
type Assistant Producer? How would that match the indexed Field if the value
added is Assistant_Producer?
On 4/13/06, Erick Erickson <[EMAIL PROTECTED]> wrote:
>
> Warning: I'm quite new to lucene, so this may not be very accurate
>
> What analyzers are yo
ncreases.
>
>
> -Original Message-
> From: Chris Lu [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 13, 2006 10:21 PM
> To: java-user@lucene.apache.org
> Subject: Re: Lucene Seaches VS. Relational database Queries
>
>
> I agree with Jelda.
>
> Lucene is
Warning: I'm quite new to lucene, so this may not be very accurate
What analyzers are you using for indexing and searching? StandardAnalyzer
(like in most of the examples)? Because it looks like you're having a
tokenizer problem. That is, when you index "Assistant producer", you
actually index
query size and
nesting increases.
-Original Message-
From: Chris Lu [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 13, 2006 10:21 PM
To: java-user@lucene.apache.org
Subject: Re: Lucene Seaches VS. Relational database Queries
I agree with Jelda.
Lucene is more document-centric. Storing
A documents information search
> in B.
> >
> > It seems for me more performant than indexing all 'A join B' documents.
> >
> > Any commenters?
> >
> > Jelda
> >
> > > -Original Message-----
> > > From: Satuluri, Venu_Madhav [mail
need to remove Documents which correspond
> > logically to the same row in A from the Hits.
> >
> > Is there a better way to do this? Or I don't make sense?
> >
> >
> > -Original Message-
> > From: Ananth T. Sarathy [mailto:[EMAIL PROTECTED]
&
gt;
>
> -Original Message-----
> From: Ananth T. Sarathy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 13, 2006 9:04 PM
> To: java-user@lucene.apache.org
> Subject: Re: Lucene Seaches VS. Relational database Queries
>
>
> Ok,
> Some of the stuff makes some sense. I was a
B join C join D.. }. Plus, we'll need to remove
> Documents which correspond logically to the same row in A from the Hits.
>
> Is there a better way to do this? Or I don't make sense?
>
>
> -Original Message-
> From: Ananth T. Sarathy [mailto:[EMAIL PROTECTED]
logically to the same row in A from the Hits.
Is there a better way to do this? Or I don't make sense?
-Original Message-
From: Ananth T. Sarathy [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 13, 2006 9:04 PM
To: java-user@lucene.apache.org
Subject: Re: Lucene Seaches VS. Relationa
Sorry, hit submit in mid email
Ok,
Some of the stuff makes some sense. I was a little loopy from lack of
sleep and some of these solutions don't really cover my concerns
Let's take this movie example. If each member of a production Crew can have
multiple titles that come from a lookup tabl
Ok,
Some of the stuff makes some sense. I was a little loopy from lack of
sleep and some of these solutions don't really cover my concerns
Let's take this movie example. If each member of a production Crew can have
multiple titles that come from a lookup table of Distinct Jobs
Titles
Assis
Chris Hostetter <[EMAIL PROTECTED]> wrote on 12/04/2006 01:41:37 AM:
> : them in one field). One of the problems I see would be with values
that
> : over lap (Example, name where one name is Jason Bateman, and one is
Jason
> : Bateman Black, and it would be hard to replicate the Discrete Search
fo
1) An inverted full text index is not a replacment for a relational
database.
2) many people think they need a relational database, when all they really
need is a well designed full text index.
To get to some of your specific questions...
: them in one field). One of the problems I see would b
23 matches
Mail list logo
