[
https://issues.apache.org/jira/browse/LUCENE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13752419#comment-13752419
]
Robert Muir commented on LUCENE-5189:
-------------------------------------
{quote}
That way you can end up with e.g. _0_Lucene45_0_1.dvd and *.dvm for field 'f'
...
I put a nocommit in DVFormat.fieldsConsumer/Producer by adding another variant
which takes fieldInfosGen.
...
I want to have only one variant of that method, thereby breaking the API. This
is important IMO cause we need to ensure that whatever custom DVFormats out
there pay attention to the new fieldInfosGen parameter, or otherwise they might
overwrite previously created files.
{quote}
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?
{quote}
SegmentCoreReaders no longer has a single DVConsumer it uses, but rather per
field it uses the appropriate DVConsumer (depends on the 'gen').
I put a nocommit to remove DVConsumers from SegCoreReaders into a
RefCount'd object in SegmentReader so that we can keep SegCoreReaders manage
the 'readers' that are shared between all SegReaders, and also make sure to
reuse same DVConsumer by multiple SegReaders. I'll do that later.
{quote}
I hope we can do this in a cleaner way than 3.x did it for setNorm, that was
really crazy :)
{quote}
I put a nocommit in DVFormat.fieldsConsumer/Producer by adding another variant
which takes fieldInfosGen.
{quote}
Can we refer to this consistently as docValuesGen or something else (I see the
patch already does this in some places, but other places its called
fieldInfosGen). I dont think this should ever be referred to as fieldInfosGen
because, its not a generation for the fieldinfos data, and that would be
horribly scary!
> 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
