[
https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732190#action_12732190
]
Hoss Man commented on LUCENE-1749:
----------------------------------
bq. :TODO: is the "int" sort type still needed? ... doesn't seem to be used
anywhere, code just tests "custom" for SortComparator vs Parser.
sorry ... badly placed quotes ... that was in referent to Entry.type.
Until i changed getStrings, getStringIndex, and getAuto to construct Entry
objects as part of my refactoring the "type" attribute (and the constructor
that takes a type argument) didnt' seem to be used anywhere (as far as i could
tell)
My guess: maybe some previous changes refactored logic that switched on type up
into the SortFields?, so the FieldCache no longer needs to care about it?
> FieldCache introspection API
> ----------------------------
>
> Key: LUCENE-1749
> URL: https://issues.apache.org/jira/browse/LUCENE-1749
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Hoss Man
> Priority: Minor
> Fix For: 2.9
>
> Attachments: fieldcache-introspection.patch
>
>
> FieldCache should expose an Expert level API for runtime introspection of the
> FieldCache to provide info about what is in the FieldCache at any given
> moment. We should also provide utility methods for sanity checking that the
> FieldCache doesn't contain anything "odd"...
> * entries for the same reader/field with different types/parsers
> * entries for the same field/type/parser in a reader and it's subreader(s)
> * etc...
--
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
