lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <>
Subject [jira] Commented: (LUCENE-2308) Separately specify a field's type
Date Fri, 12 Mar 2010 22:25:35 GMT


Chris Male commented on LUCENE-2308:

I will, if I can (provided the FieldType does not contain the field name). That shouldn't
have anything to do with immutability though.

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.

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.

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:
>             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:
For additional commands, e-mail:

View raw message