[
https://issues.apache.org/jira/browse/LUCENE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2846:
--------------------------------
Attachment: LUCENE-2846.patch
here's an initial patch hacked up by mike and I... also removed the
"multireader norms" method that
takes a byte[]+offset from IndexReader.
one oddity is that MultiNorms.norms() always returns a filled byte[] here for
non-atomic readers (never null).
But i think this is ok for MultiNorms, its not used in searching (only for
SlowMultiReaderWrapper etc)
i think somehow it would be good to have more tests that test "doesnt have
field" versus "omits norms",
and also (likely not in this is issue) we should think about IR's norm-setting
methods.
I don't like that these use Similarity.getDefault(): it seems we could require
you to pass in the Sim for the float case.
I also don't like that we expose a public setNorm that takes a byte value
either!
Long-term we should look at pulling this norm-encoding stuff out of Sim... the
Sim should just be dealing with floats,
this encoding stuff belongs somewhere else.
> omitTF is viral, but omitNorms is anti-viral.
> ---------------------------------------------
>
> Key: LUCENE-2846
> URL: https://issues.apache.org/jira/browse/LUCENE-2846
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-2846.patch
>
>
> omitTF is viral. if you add document 1 with field "foo" as omitTF, then
> document 2 has field "foo" without omitTF, they are both treated as omitTF.
> but omitNorms is the opposite. if you have a million documents with field
> "foo" with omitNorms, then you add just one document without omitting norms,
> now you suddenly have a million 'real norms'.
> I think it would be good for omitNorms to be viral too, just for consistency,
> and also to prevent huge byte[]'s.
> but another option is to make omitTF anti-viral, which is more "schemaless" i
> guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
