[
https://issues.apache.org/jira/browse/LUCENE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752424#comment-13752424
]
Shai Erera commented on LUCENE-5189:
------------------------------------
bq. Can we refer to this consistently as docValuesGen
Yes, I think that makes sense. At some point I supported this by gen'ing
FieldInfos hence the name, but things have changed since. I'll rename.
bq. Maybe we shouldnt pass this parameter to the codec at all. Instead
IndexWriter can just put this into the segment suffix and the codec can be
blissfully unaware?
Maybe for writing it can work, but the producer needs to know from which
Directory to read the file, e.g. if it's CFS, the gen'd files are written
outside. I have this code in Lucene45DVProducer:
{code}
final Directory dir;
if (fieldInfosGen != -1) {
dir = state.segmentInfo.dir; // gen'd files are written outside CFS, so
use SegInfo directory
} else {
dir = state.directory;
}
{code}
I think that if we want to mask that away from the Codec entirely, we should
somehow tell the Codec the segmentSuffix and the Directory from which to read
the file. Would another Directory parameter be confusing (since we also have it
in SegReadState)?
bq. I hope we can do this in a cleaner way than 3.x did it for setNorm, that
was really crazy
Well ... I don't really know how setNorm worked in 3.x, so I'll do what I think
and you tell me if it's crazy or not? :)
> Numeric DocValues Updates
> -------------------------
>
> Key: LUCENE-5189
> URL: https://issues.apache.org/jira/browse/LUCENE-5189
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/index
> Reporter: Shai Erera
> Assignee: Shai Erera
> Attachments: LUCENE-5189.patch
>
>
> In LUCENE-4258 we started to work on incremental field updates, however the
> amount of changes are immense and hard to follow/consume. The reason is that
> we targeted postings, stored fields, DV etc., all from the get go.
> I'd like to start afresh here, with numeric-dv-field updates only. There are
> a couple of reasons to that:
> * NumericDV fields should be easier to update, if e.g. we write all the
> values of all the documents in a segment for the updated field (similar to
> how livedocs work, and previously norms).
> * It's a fairly contained issue, attempting to handle just one data type to
> update, yet requires many changes to core code which will also be useful for
> updating other data types.
> * It has value in and on itself, and we don't need to allow updating all the
> data types in Lucene at once ... we can do that gradually.
> I have some working patch already which I'll upload next, explaining the
> changes.
--
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
