[
https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844720#action_12844720
]
Chris Male commented on LUCENE-2308:
------------------------------------
{quote}
I will, if I can (provided the FieldType does not contain the field name). That
shouldn't have anything to do with immutability though.
{quote}
Yeah the field name will stay inside the Field. To me the reuse issue relates
immutability in that a change to a property in one FieldType after construction
means the change effects all the Fields that use that type.
But as you say, if we document that its best to set everything at instantiation
and that whatever happens after that is undefined, then I imagine it'll be fine.
{quote}
new Field instances should be fine - it's not really my use case anyway. But
we're designing for the 1000's of use cases that are out there and we should be
careful about adding new constraints.
{quote}
Yeah I appreciate that this API will be used in lots of different ways. Baby
steps as Mike said :) But to answer your question, yes the flexibility will
remain.
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
