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 Sat, 24 Sep 2011 14:25:26 GMT


Chris Male commented on LUCENE-3312:

Back on this wagon for a bit.

Just wondering about whether we need a StorableFieldType to accompany StorableField.

At this stage I've struggling to identify candidate properties for a StorableFieldType.  Options
include moving the Numeric.DataType and DocValues' ValueType to the FieldType.  While I sort
of like this idea, it seems to have a couple of disadvantages:

- Any FieldTypes passed into NumericField and IndexDocValuesField would have to have these
properties set from the beginning.  For both of these, this would mean it wouldn't be possible
to simple initialize a field and then use one of the setters to define the Data/ValueType
- they would need to be known at construction.
- It separates the 'data type' away from the actual value.

If these properties were to stay on StorableFieldType, I can't really see the need for a StorableFieldType.

> 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