lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3312) Break out StorableField from IndexableField
Date Tue, 30 Aug 2011 12:49:37 GMT


Chris Male commented on LUCENE-3312:

Good question... I think the userland "Field" (oal.document) should
implement both IndexableField and StorableField? And then
oal.document.Document holds Field instances?

Hm I'm going round in circles on this.  For building and indexing a Document, having the class
hold Field instances is easiest and the most clean option.  However this then means we are
once again providing Field instances in the Document returned by reader.document(), meaning
we lose:

So I consider this (these indexing details are no longer available
when you pull the document) a big benefit of cutting over to
StorableField. Ie, its trappy today since it's buggy, so we'd be
removing that trap.

Thoughts? :/

> Break out StorableField from IndexableField
> -------------------------------------------
>                 Key: LUCENE-3312
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index
>            Reporter: Michael McCandless
>             Fix For: Field Type branch
> 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
> in oal.document.
> Similarly, with LUCENE-3309, we've done the same thing on the
> doc/field retrieval side (from IndexReader), with the
> StoredFieldsVisitor.
> 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....

This message is automatically generated by JIRA.
For more information on JIRA, see:


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

View raw message