[
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: [email protected]
For additional commands, e-mail: [email protected]
