[
https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095016#comment-13095016
]
Chris Male commented on LUCENE-2308:
------------------------------------
Just when I thought we had some consensus...
{quote}
After all, if this is to just be a holder for parameters (like indexed, stored,
etc) then allowing one to subclass doesn't add any power or even make much
sense (they aren't going to change the "behavior" of anything, right?) The
other normal use cases for interfaces wouldn't seem to apply to this situation
either.
{quote}
I don't see the interface just holding a series of boolean properties. I've
long favored moving Analyzer there (lets not fight that fight here) and
information about numeric datatypes and docvalues types probably belong there
too. I've also explored using Attributes to provide context specific
extensions (more datatypes ideas, uniqueness, spatial info) that allow
customized indexing of Fields.
Equally, we have moved towards liberating the core indexer code from
implementations of these concepts, starting with IndexableField and moving onto
StorableField (if I ever get there). I don't see it as overkill for the
indexer to rely on the interface for FieldType too.
> 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
