[ 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