[
https://issues.apache.org/jira/browse/LUCENE-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785921#action_12785921
]
Michael McCandless commented on LUCENE-2111:
--------------------------------------------
bq. The LegacyTermsEnum correctly seeks to the first Term/TermRef but as the
deprec TermEnum still iterates after the last term, the TermsEnum returns all
terms from all later fields, too. So seek() and next() should also do a
field==Term.field() comparison and set SeekStatus/return value correctly.
Nice catch -- I'll open a new issue & fix.
bq. Also (you see it because missing @Override): The new abstract Enums have no
close method / not implement java.io.Closeable, so the underlying old enums are
never closed by client code. Shouldn't all the enum classes not also be
Closeable, even when the new Codec API current would implement these as a no-op
for core classes. But maybe someone creates a codec that needs close?
I actually intentionally left .close() out of all *Enums.
First, to strongly bias impls from doing such costly things that close
is necessary. These enums are used in hotspots during searching.
Second, because for Lucene's core impls, close() is [almost?] always a
no-op: these impls are very lightweight.
Third, because in Lucene we don't consistently close the enums we
pull, today, so we have confusion (there have been posts to java-user
about this -- "do I need to close the TermEnum/TermDocs"). I'd rather
not add a "close" that for all core impls is a no-op and so Lucene
doesn't have to call close.
Fourth, because it complicates our impls if we really must close
whenever we pull a enum -- eg our Scorers pull enums today, but never
close them.
> Wrapup flexible indexing
> ------------------------
>
> Key: LUCENE-2111
> URL: https://issues.apache.org/jira/browse/LUCENE-2111
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: Flex Branch
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.1
>
>
> Spinoff from LUCENE-1458.
> The flex branch is in fairly good shape -- all tests pass, initial search
> performance testing looks good, it survived several visits from the Unicode
> policeman ;)
> But it still has a number of nocommits, could use some more scrutiny
> especially on the "emulate old API on flex index" and vice/versa code paths,
> and still needs some more performance testing. I'll do these under this
> issue, and we should open separate issues for other self contained fixes.
> The end is in sight!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
