lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-1626) getPositionIncrementGap(String fieldname, int currentPos)
Date Fri, 01 May 2009 19:07:30 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man updated LUCENE-1626:
-----------------------------

    Attachment: LUCENE-1626-positionincrement.patch

the same patch Paul Cowan attached to LUCENE-1626 addressing this idea (prior to me cloning
the issue)

> getPositionIncrementGap(String fieldname, int currentPos)
> ---------------------------------------------------------
>
>                 Key: LUCENE-1626
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1626
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Search
>    Affects Versions: 2.4
>            Reporter: Paul Cowan
>            Priority: Minor
>         Attachments: LUCENE-1626-positionincrement.patch
>
>
> This issue is to cover the changes required to do a search across multiple fields with
the same name in a fashion similar to a many-to-one database. Below is my post on java-dev
on the topic, which details the changes we need:
> (sniped to only second idea ... see LUCENE-1494 for background and first idea)
> 2) It gets slightly more complicated in the case of variable-length terms. For example,
imagine if we had an 'address' field ('123 Smith St') which will result in (1 to n) tokens;
slop 0 in a SpanNearQuery won't work here, of course. One thing we've toyed with is the idea
of using getPositionIncrementGap -- if we knew that 'address' would be, at most, 20 tokens,
we might use a position increment gap of 100, and make the slop factor 50; this works fine
for the simple case (yay!), but with a great many addresses-per-user starts to get more complicated,
as the gap counts from the last term (so the position sequence for a single value field might
be 0, 100, 200, but for the address field it might be 0, 1, 2, 3, 103, 104, 105, 106, 206,
207... so it's going to get out of sync). The simplest option here seems to be changing (or
supplementing)
>    public int getPositionIncrementGap(String fieldname)
> to
>    public int getPositionIncrementGap(String fieldname, int currentPos)
> so that we can override that to round up to the nearest 100 (or whatever) based on currentPos.
The default implementation could just delegate to getPositionIncrementGap().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message