lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (JIRA)" <>
Subject [jira] [Updated] (LUCENE-4491) Make analyzing suggester more flexible
Date Fri, 19 Oct 2012 09:30:14 GMT


Simon Willnauer updated LUCENE-4491:

    Attachment: LUCENE-4491.patch

this patch moves all the explicit bytes to char conversions into protected methods, adds a
TermFreqIterator#surfaceForm method and opens up LookupResult for subclassing. I also added
a test that shows the possibilities for custom extension. All tests pass.
> Make analyzing suggester more flexible
> --------------------------------------
>                 Key: LUCENE-4491
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/other
>    Affects Versions: 4.1
>            Reporter: Simon Willnauer
>            Assignee: Simon Willnauer
>             Fix For: 4.1, 5.0
>         Attachments: LUCENE-4491.patch
> Today we have a analyzing suggester that is bound to a single key. Yet, if you want to
have a totally different surface form compared to the key used to find the suggestion you
either have to copy the code or play some super ugly analyzer tricks. For example I want to
suggest "Barbar Streisand" if somebody types "strei" in that case the surface form is totally
different from the analyzed form. 
> Even one step further I want to embed some meta-data in the suggested key like a user
id or some type my surface form could look like "Barbar Streisand|15". Ideally I want to encode
this as binary and that might not be a valid UTF-8 byte sequence.
> I'm actually doing this in production and my only option was to copy the analyzing suggester
and some of it's related classes.

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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message