[ 
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

Reply via email to