[
https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13094486#comment-13094486
]
Uwe Schindler edited comment on LUCENE-2308 at 8/31/11 12:46 PM:
-----------------------------------------------------------------
Thats not a bug if you implement it correctly, in general a Builder/Factory
combination is the solution. The Builder itsself is mutable. The last call on
the builder is something like .createField() that no longer returns a Builder
instance, but instead the immutable field. Thats all. All calls before use the
same builder instance and always returning itsself. See e.g. Google
Collections, they have their builders implemented exactly that way.
{code:java}
Field field1 = new FieldBuilder(name).setFoo().setBar().createField();
{code}
And for indexing you can even reuse the builder to produce many identical
fields:
{code:java}
FieldBuilder builder = new FieldBuilder(name).setFoo().setBar();
for (documents) {
Field field1 = builder.createField();
}
{code}
was (Author: thetaphi):
Thats not a bug if you implement it correctly, in general a Builder/Factory
combination is the solution. The Builder itsself is mutable. The last call on
the builder is something like .createField() that no longer returns a Builder
instance, but instead the immutable field. Thats all. All calls before use the
same builder instance and always returning itsself. See e.g. Google
Collections, they have their builders implemented exactly that way.
{code:java}
Field field1 = new FieldBuilder(name).setFoo().setBar().createField();
{code}
> 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: core/index
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Labels: gsoc2011, lucene-gsoc-11, mentor
> Fix For: 4.0
>
> Attachments: LUCENE-2308-10.patch, LUCENE-2308-11.patch,
> LUCENE-2308-12.patch, LUCENE-2308-13.patch, LUCENE-2308-14.patch,
> LUCENE-2308-15.patch, LUCENE-2308-16.patch, LUCENE-2308-17.patch,
> LUCENE-2308-18.patch, LUCENE-2308-19.patch, LUCENE-2308-2.patch,
> LUCENE-2308-20.patch, LUCENE-2308-21.patch, LUCENE-2308-3.patch,
> LUCENE-2308-4.patch, LUCENE-2308-5.patch, LUCENE-2308-6.patch,
> LUCENE-2308-7.patch, LUCENE-2308-8.patch, LUCENE-2308-9.patch,
> LUCENE-2308-branch.patch, LUCENE-2308-final.patch, LUCENE-2308-ltc.patch,
> LUCENE-2308-merge-1.patch, LUCENE-2308-merge-2.patch,
> LUCENE-2308-merge-3.patch, LUCENE-2308.branchdiffs,
> LUCENE-2308.branchdiffs.moved, LUCENE-2308.patch, LUCENE-2308.patch,
> LUCENE-2308.patch, LUCENE-2308.patch, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
