n solve this by
indexing such fields twice: once as keyword to search for the specific
individual, and once with indexed terms to search for name(s).
In both fields one could use an extra word from a relational db,
for example a client id.
Regards,
Paul Elschot
> View this message in context:
e accurate
text-searching even if somthing on our index for 1: "Jason" and "Jason
Black" relationship, then we should just simply say we cannot implement this
because lucene search will yield inaccurate results correct???
comments?
--
View this message in context:
http:/
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
H,
We have made documents out of the rows in our database and one of the team
is suggesting that we abandon some of our database queries and instead use
lucene. I think there are some fundamental problems with this especially
when it comes to association tables (where there is a 1 one to many
rela
24 matches
Mail list logo
