[ 
https://issues.apache.org/jira/browse/LUCENE-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007150#comment-14007150
 ] 

Shai Erera commented on LUCENE-5680:
------------------------------------

bq. why do we have both MISSING and createMissing? It seems only one is 
necessary.

It's because I didn't want to add a ctor to NDVField which takes a Long. And if 
the user will want to create that, by e.g. creating a new NDVField w/ dummy 
value, then call setNumberValue, it's possible. But then NDVField ctor will 
create a Long object out of the dummy value .. a waste.

You know what, perhaps we can leave unsetting through the atomic API out of the 
picture for now, and handle it when the need arises. Maybe we should also nuke 
that from the other updateXXXDocValue? I.e. if the need arises, we fix all of 
them, and make them consistent?

> Allow updating multiple DocValues fields atomically
> ---------------------------------------------------
>
>                 Key: LUCENE-5680
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5680
>             Project: Lucene - Core
>          Issue Type: New Feature
>          Components: core/index
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>         Attachments: LUCENE-5680.patch, LUCENE-5680.patch, LUCENE-5680.patch
>
>
> This has come up on the list (http://markmail.org/message/2wmpvksuwc5t57pg) 
> -- it would be good if we can allow updating several doc-values fields, 
> atomically. It will also improve/simplify our tests, where today we index two 
> fields, e.g. the field itself and a control field. In some multi-threaded 
> tests, since we cannot be sure which updates came through first, we limit the 
> test such that each thread updates a different set of fields, otherwise they 
> will collide and it will be hard to verify the index in the end.
> I was working on a patch and it looks pretty simple to do, will post a patch 
> shortly.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to