[
https://issues.apache.org/jira/browse/LUCENE-5148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722449#comment-13722449
]
Simon Willnauer commented on LUCENE-5148:
-----------------------------------------
+1 on removing the trap. Yet, it would be nice to make this object entirely
stateless if possible. I can think of 2 options:
{noformat}
public LongsRef getOrds(int docId, LongsRef spare)
{noformat}
this has the advantage that we can easily reuse a LongsRef on top which is kind
of consistent with other API in Lucene
or maybe add an OrdsIterator like this
{noformat}
public OrdsIter getOrds(int docId, OrdsIter spare)
// Iterate like this:
int ord;
while( (ord = ordsIter.nextOrd()) != NO_MORE_ORDS) {
...
}
{noformat}
mainly thinking about consistency regarding other apis here but I don't like
the stateful API we have right now.
> 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]
