[
https://issues.apache.org/jira/browse/LUCENE-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13777279#comment-13777279
]
Shai Erera commented on LUCENE-5215:
------------------------------------
bq. e.g. search for 4.5, Lucene45, such strings in eclipse
Good idea. I searched for references to Lucene45Codec, and fixed them. I now
searched for "4.5", "45" and "lucene45" and found few other places to fix.
bq. wherever you see @Deprecated (eg Lucene45Codec) ensure @deprecated <reason>
in javadocs too
done.
bq. the SegmentReader.readFieldInfos seems an awkward place to me for this:
must it really be public or can it be package-private?
I tried to find a good place for it too, and chose SegmentReader since it's
mostly needed by it. As for package-private, it's also accessed by
_TestUtil.getFieldInfos, but I see the only tests that call it are under
o.a.l.index, so I think for now we can make it package-private and get rid of
_TestUtil.getFieldInfos? Note that it's also marked @lucene.internal.
bq. In perFieldDocValuesFormat where we have suffixAtt =
Integer.valueOf(suffixAtt);, do we have any concerns?
Isn't it increased per unique format? I don't mind changing it to a long, but
do we really expect more than Integer.MAX_VAL formats!?
> Add support for FieldInfos generation
> -------------------------------------
>
> Key: LUCENE-5215
> URL: https://issues.apache.org/jira/browse/LUCENE-5215
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/index
> Reporter: Shai Erera
> Assignee: Shai Erera
> Attachments: LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch,
> LUCENE-5215.patch, LUCENE-5215.patch, LUCENE-5215.patch
>
>
> In LUCENE-5189 we've identified few reasons to do that:
> # If you want to update docs' values of field 'foo', where 'foo' exists in
> the index, but not in a specific segment (sparse DV), we cannot allow that
> and have to throw a late UOE. If we could rewrite FieldInfos (with
> generation), this would be possible since we'd also write a new generation of
> FIS.
> # When we apply NDV updates, we call DVF.fieldsConsumer. Currently the
> consumer isn't allowed to change FI.attributes because we cannot modify the
> existing FIS. This is implicit however, and we silently ignore any modified
> attributes. FieldInfos.gen will allow that too.
> The idea is to add to SIPC fieldInfosGen, add to each FieldInfo a dvGen and
> add support for FIS generation in FieldInfosFormat, SegReader etc., like we
> now do for DocValues. I'll work on a patch.
> Also on LUCENE-5189, Rob raised a concern about SegmentInfo.attributes that
> have same limitation -- if a Codec modifies them, they are silently being
> ignored, since we don't gen the .si files. I think we can easily solve that
> by recording SI.attributes in SegmentInfos, so they are recorded per-commit.
> But I think it should be handled in a separate issue.
--
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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
