[
https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-1749:
-----------------------------
Attachment: LUCENE-1749-hossfork.patch
This is a complete overhaul of the internals of FieldCacheSanityChecker, and
it's API so that it's a lot cleaner and easier to use programaticly.
This also makes it easier for tests to run an analsis, and then ignore the
_types_ of errors they "expect" without ignoring whole cache entries (so a test
that expects to have subreader problems can ignore those, even if one of those
cache entires also fails a sanity check with another entry for a different
reason (ie: different parser on same reader)
And in the long run: this should make it easier for us to add new types of
sanity checks (which i'm guessing we'll think of when the internals get
overhauled) without changing the API too much.
*NOTE:* This is based on Miller's attachment #12414960 (29/Jul/09) ... i
haven't merged in or looked at any of the changes he made after that. i
suspect the only overlap (if any) is how CacheEntry uses the Ram Estimation
code ... i switched to having estimateSize(RamUsageEstimator) cache the value
and then toString uses it if it's there ... the FieldCacheSanityChecker takes
care of calling it if the client code asks for it.
Mark: viv's got all weekend off, so i'm probably not going to have time to look
at this again for 4 or 5 days, if you want to take a stab at merging the
patches thta would be seriously awesome.
> 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,
> LUCENE-1749-hossfork.patch, LUCENE-1749.patch, LUCENE-1749.patch,
> LUCENE-1749.patch, LUCENE-1749.patch, LUCENE-1749.patch, LUCENE-1749.patch,
> LUCENE-1749.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: [email protected]
For additional commands, e-mail: [email protected]
