Yeah, I have no problem breaking them out in the end (and am trying to
also track with separate JIRA issues). For right now its easier to keep
it here though - since this is the code thats catching the bugs, and has
the code to keep checking without having to juggle multiple patches. And
the checks could change or be added to. I'll be happy to break the bug
fix code pieces out to their respective issues when we are done here
(it's really only one issue at the moment I think - though you could
argue two I guess), or before when it makes sense or if it ends up
confusing the main issue here. Right now, the code for the fixes is very
minor and easy to manage.
- Mark
Chris Hostetter wrote:
: changes to just go per reader for each doc - and a couple other unrelated
tiny tweaks.
FWIW: now that this issues has uncovered a few genuine "bugs" in code (as
opposed to justs tests being odd) it would probably be better to track
those bugs and their patches in seperate issues that can be individually
refered to in CHANGES.txt (and reopened as needed)
committing those bug fixes can be done independently of commiting the
sanity checker.
(PS: i'm making this suggestiong based purely on skiming the jiraemail
stream from the last day or so ... i haven't looked at the patches but the
decriptions seem to suggest they contain actual bug fixes, not just test
modifications)
:
: > 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, 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: java-dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: java-dev-h...@lucene.apache.org
:
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
