In the field type branch we have strongly decoupled
Document/Field/FieldType impl from the indexer, by having only a
narrow API (IndexableField) passed to IndexWriter. This frees apps up
use their own "documents" instead of the "user-space" impls we provide
LUCENE-3309, we've done the same thing on the
doc/field retrieval side (from IndexReader), with the
But, maybe we should break out StorableField from IndexableField,
such that when you index a doc you provide two Iterables – one for the
IndexableFields and one for the StorableFields. Either can be null.
One downside is possible perf hit for fields that are both indexed &
stored (ie, we visit them twice, lookup their name in a hash twice,
etc.). But the upside is a cleaner separation of concerns in API....
- is related to
LUCENE-4637 Using StringField for while storing becomes a regular Field when the document is retrieved - Due to this the next search cannot find the document because the value of the Field got tokenized which was not desired when it was added
- is superceded by
LUCENE-4347 Fix remaining issues with StorableField