[
https://issues.apache.org/jira/browse/LUCENE-5148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722475#comment-13722475
]
Robert Muir commented on LUCENE-5148:
-------------------------------------
these other options have downsides too.
LongsRef has all the disadvantages of the *Ref APIs (e.g. reuse bugs), also
requires reading all the ordinals into RAM at once.
Adding an additional iterator just pushes the problem into a different place to
me, and makes the api more complex.
The current threadlocal + state is at least simple, consistent with all of the
other docvalues, and documented that it works this way.
If we want to change the API, then I think we need to consider all of these
issues.
> SortedSetDocValues caching / state
> ----------------------------------
>
> Key: LUCENE-5148
> URL: https://issues.apache.org/jira/browse/LUCENE-5148
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Priority: Minor
>
> I just spent some time digging into a bug which was due to the fact that
> SORTED_SET doc values are stateful (setDocument/nextOrd) and are cached per
> thread. So if you try to get two instances from the same field in the same
> thread, you will actually get the same instance and won't be able to iterate
> over ords of two documents in parallel.
> This is not necessarily a bug, this behavior can be documented, but I think
> it would be nice if the API could prevent from such mistakes by storing the
> state in a separate object or cloning the SortedSetDocValues object in
> SegmentCoreReaders.getSortedSetDocValues?
> What do you think?
--
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: [email protected]
For additional commands, e-mail: [email protected]
