[
https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159515#comment-14159515
]
Robert Muir commented on LUCENE-5989:
-------------------------------------
{quote}
This is supremely expert, I wonder if anyone out there has succeeded
in doing so?
{quote}
So the solution is to proceed and make matters worse by requiring the user to
*also* deal with the .document API?
If the user wants their field to work with various query-time features
(queryparser, morelikethis, whatever), then they must deal with the tokenstream
side anyway, so adding *Field doesn't help anything. It just adds yet another
place they must plug in "schema" information (as opposed to only being once in
Analyzer). Sure, its easier to get past indexwriter maybe, but you win the
battle and lose the war.
I'm not going to try to block the change, just please, please, please think
about it.
> Add BinaryField, to index a single binary token
> -----------------------------------------------
>
> Key: LUCENE-5989
> URL: https://issues.apache.org/jira/browse/LUCENE-5989
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-5989.patch
>
>
> 5 years ago (LUCENE-1458) we "enabled" fully binary terms in the
> lowest levels of Lucene (the codec APIs) yet today, actually adding an
> arbitrary byte[] binary term during indexing is far from simple: you
> must make a custom Field with a custom TokenStream and a custom
> TermToBytesRefAttribute, as far as I know.
> This is supremely expert, I wonder if anyone out there has succeeded
> in doing so?
> I think we should make indexing a single byte[] as simple as indexing
> a single String.
> This is a pre-cursor for issues like LUCENE-5596 (encoding IPv6
> address as byte[16]) and LUCENE-5879 (encoding native numeric values
> in their simple binary form).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
