[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113984#comment-13113984
]
Chris Male edited comment on LUCENE-3312 at 9/24/11 2:25 PM:
-------------------------------------------------------------
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 StorableField, I can't really see the need
for a StorableFieldType.
was (Author: cmale):
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: https://issues.apache.org/jira/browse/LUCENE-3312
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
