[
https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated LUCENE-2308:
-------------------------------
Attachment: LUCENE-2308.patch
Throwing my ideas into the ring. Currently just the implementation of
FieldType (I'm waiting on LUCENE-2310 before attacking Field). I've tried to
incorporate all the various ideas suggested here.
- FieldType has two constructors, modeled along the same lines as what Marvin
suggested.
- Introduces a simplified Attribute concept (FieldTypeAttribute) that allows
context specific extensions to FieldType to be added. An example of this would
be a SpatialAttribute that provides more information about the spatial
information stored in a certain field. AttributeSource and Attribute were not
used since they really seem designed around the AttributeFactory idea, which
seems unnecessary here, and that the content of Attributes could change often,
rather than being readonly as I would prefer them here.
- FieldTypeBuilder provides a fluid interface for creating FieldTypes, much
like IndexWriterConfig.
- FieldType is readonly.
> Separately specify a field's type
> ---------------------------------
>
> Key: LUCENE-2308
> URL: https://issues.apache.org/jira/browse/LUCENE-2308
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Michael McCandless
> Labels: gsoc2011, lucene-gsoc-11, mentor
> Fix For: 4.0
>
> Attachments: LUCENE-2308.patch
>
>
> This came up from dicussions on IRC. I'm summarizing here...
> Today when you make a Field to add to a document you can set things
> index or not, stored or not, analyzed or not, details like omitTfAP,
> omitNorms, index term vectors (separately controlling
> offsets/positions), etc.
> I think we should factor these out into a new class (FieldType?).
> Then you could re-use this FieldType instance across multiple fields.
> The Field instance would still hold the actual value.
> We could then do per-field analyzers by adding a setAnalyzer on the
> FieldType, instead of the separate PerFieldAnalzyerWrapper (likewise
> for per-field codecs (with flex), where we now have
> PerFieldCodecWrapper).
> This would NOT be a schema! It's just refactoring what we already
> specify today. EG it's not serialized into the index.
> This has been discussed before, and I know Michael Busch opened a more
> ambitious (I think?) issue. I think this is a good first baby step. We could
> consider a hierarchy of FIeldType (NumericFieldType, etc.) but maybe hold
> off on that for starters...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
