[ 
https://issues.apache.org/jira/browse/LUCENE-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160259#comment-14160259
 ] 

Robert Muir commented on LUCENE-5989:
-------------------------------------

Why jump to the conclusion that a user would have a byte[] already for an IP 
address? Thats a horrible representation Why wouldn't they pass 
java.net.Inet6Address?

I'm just saying that if they then go do the following in queryparser, why can't 
it please work? (ranges too)

{code}
... AND address:"1.2::3.4" 
{code}

Otherwise, if we don't want to make binary/numeric/etc fields "first class", 
and only treat them as bastardizations of text fields, then please, do this 
consistently everywhere, parse them as text everywhere, so that they will work 
correctly everywhere.


> 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]

Reply via email to