[
https://issues.apache.org/jira/browse/LUCENE-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185524#comment-13185524
]
Robert Muir commented on LUCENE-3687:
-------------------------------------
I just saw DocValuesField has this same problem. Ill open a separate issue for
that.
But this is a real serious trap. Overloading setint as setInt(short)
setInt(int) setInt(byte) setInt(long),
besides being confusing (and I see no advantage to doing this), has the nice
property
of easily quadrupling peoples norms with no type safety unless they are like,
peeking at
their generated bytecode to verify java didn't promote them up to setInt(int)
by making it setByte(byte) instead, if they don't pass an actual byte they will
get
a compile error.
> Allow similarity to encode norms other than a single byte
> ---------------------------------------------------------
>
> Key: LUCENE-3687
> URL: https://issues.apache.org/jira/browse/LUCENE-3687
> Project: Lucene - Java
> Issue Type: New Feature
> Components: core/index, core/search
> Affects Versions: 4.0
> Reporter: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-3687.patch, LUCENE-3687.patch, LUCENE-3687.patch
>
>
> LUCENE-3628 cut over norms to docvalues. This removes the long standing
> limitation that norms are a single byte. Yet, we still need to expose this
> functionality to Similarity to write / encode norms in a different format.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
