You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2013/03/16 20:18:12 UTC
[jira] [Resolved] (LUCENE-1626) getPositionIncrementGap(String
fieldname, int currentPos)
[ https://issues.apache.org/jira/browse/LUCENE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Erickson resolved LUCENE-1626.
------------------------------------
Resolution: Won't Fix
SPRING_CLEANING_2013. We can reopen if there's interest.
> getPositionIncrementGap(String fieldname, int currentPos)
> ---------------------------------------------------------
>
> Key: LUCENE-1626
> URL: https://issues.apache.org/jira/browse/LUCENE-1626
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org