lucene-dev mailing list archives

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


Simon Willnauer commented on LUCENE-4491:

bq. This is an iterator of terms + freqs... 'surface form' is a concept only within analyzing
fair enough. maybe we could use the Attribute API for this? I had this in mind too but this
was the simplest thing I could do so I started with this.
> 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