lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Fieldable, AbstractField, Field
Date Mon, 24 Mar 2008 21:14:24 GMT

: IndexReader would not instantiate a subclass in this example.  I was just
: saying your wrapping example doesn't require an interface: it works equally
: well if ReadOnlyDocument is a concrete class.  I think moving away from
: interfaces for 3.0 makes sense.

i don't know that it works equally well.  but i agree it can work.

"moving away from interfaces" is more of a concrete statement then i'd 
like to make ... moving away from big interfaces yes, but i think 
there are probably situation in the Lucene code base where more simple 
"" type interfaces (in the vein of Callable, Runnable, etc...) 
could make sense.

: Agreed, it's a dangerous trap to make this look simple.  EG, I just discovered
: that if you call "isIndexed()" on a Fieldable in the document returned by an
: IndexReader, it can lie, because it falls back to FieldInfos to check that
: field.  But this is not right since on adding the one doc you could have
: specified NOT to index that one field and only store it.  Also, getBoost()
: doesn't survive indexing.  In short, it's buggy, today, that we try to act
: like a retrieved document has faithfully preserved these detailed index-time
: settings.

bingo ... just because things have the same name, doesn't mean they should 
*be* the same implementation from a common base class.

: So the IndexableDocument abstract base class would only define getters.

well, also some protected variables backing up those getters, either that 
or make all of them abstract ... but yeah.

: StoredDocument abstract base class would only define getters.  There would be
: a (package-)private class in  that subclasses this and adds private
: setters.  Likewise for Field, or, maybe StoredDocument deals directly in
: String and doesn't make Field classes (Yonik's idea).

i would certain vote for StoredDocument implementing Map<String,Iterable<String>>

: I've flipped here and would be happy not to expose any of this API in the
: returned document.

...the key being that if we do return those types of things aas part of 
the "document" they should be via methods which are not the same as the 
methods used when indexing ... perhaps they should even 
be part of a "DocumentMetadata" object which you have to explicitly ask 
for either when fetching the document or later via docId (so people that 
just want fast access to to the stored fields can save some cycles)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message