: How do you set the position increment gap between each addition to the
it does't have an explicit setter, you just subclass that Analyzer of your
choosing and override getPositionIncrementGap to return the value of your
choosing -- it could be a fixed value, or your Analyzer could be
sophistica
How do you set the position increment gap between each addition to the
same field name. Should you set it as high as possible to prevent
proximity queries from crossing it? I have been looking for the code to
find out how to put a gap between each same name field addition, but I
have been unabl
Thanks. I think I grasp the concept now :)
On 8/27/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Aug 26, 2006, at 5:11 AM, KEGan wrote:
> Erik,
>
> "Given the position increment gap between instances of same-named
> fields that is now part of Lucene, I recommend using multiple field
> instanc
On Aug 26, 2006, at 5:11 AM, KEGan wrote:
Erik,
"Given the position increment gap between instances of same-named
fields that is now part of Lucene, I recommend using multiple field
instances instead."
Did you mean ... recommend "NOT" using multiple field ?
I said what I meant accurately. C
Erik,
"Given the position increment gap between instances of same-named
fields that is now part of Lucene, I recommend using multiple field
instances instead."
Did you mean ... recommend "NOT" using multiple field ?
If we want to do query like "name:John" or boasting of Fields ... then we
have
Thanks for everyone's help. I understand how it works now. I can get rid
of MultiFieldQueryParser in search.
thanks
suba suresh.
Erik Hatcher wrote:
Yeah, I used a cruder form by appending all the text together into a
single string with a space separator in that LIA example.
Given the posit
Yeah, I used a cruder form by appending all the text together into a
single string with a space separator in that LIA example.
Given the position increment gap between instances of same-named
fields that is now part of Lucene, I recommend using multiple field
instances instead.
Er
I think I start to understand this :) .. Thanks guys.
~KEGan
On 8/24/06, Gopikrishnan Subramani <[EMAIL PROTECTED]> wrote:
Erik's has used a space as the field separator. May be you can use a
different field separator that your analyzer won't eat up, so that will
change the token position by
Erik's has used a space as the field separator. May be you can use a
different field separator that your analyzer won't eat up, so that will
change the token position by 1.
Gopi
On 8/24/06, KEGan <[EMAIL PROTECTED]> wrote:
Erik,
What is generally the reason for indexing both individual fields
: What is generally the reason for indexing both individual fields, and the
: general-purpose "content" field ?
so you can explicitly query for "name:paris" or "city:paris" instead of
just "paris"
: name : John Smith
: food : subway sandwich
:
: So the general-purpose "content" would have the f
Erik,
What is generally the reason for indexing both individual fields, and the
general-purpose "content" field ?
Also, if we search in the general-purpose "content" field, wouldnt this
problem occurs. Let say we have 2 fields and the following values:
name : John Smith
food : subway sandwich
On Aug 23, 2006, at 11:36 AM, Suba Suresh wrote:
In "Lucene In Action" book it says it is better practice to combine
two fields into one field and index it than use the
MultiFieldQueryParser. Do I initially index both the fields and
then index them again together? When I index them together
In "Lucene In Action" book it says it is better practice to combine two
fields into one field and index it than use the MultiFieldQueryParser.
Do I initially index both the fields and then index them again together?
When I index them together do I index the fieldnames or values? Can
someone giv
13 matches
Mail list logo
