[jira] [Updated] (LUCENE-3177) Decouple indexer from Document/Field impls

["Michael McCandless (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael McCandless updated LUCENE-3177:
---------------------------------------

    Attachment: LUCENE-3177.patch

Patch.

Tests pass, but there are many nocommits.

I was *almost* able to create only IndexableField, so that
IW.addDocument took Iterable<IndexableField>, except for doc level
boost, so I had to create IndexableDocument.

I also cutover to a .binaryValue(BytesRef reuse) API here, replacing
getBinaryValue/Length/Offset.

I would actually like to take IndexableDocument/Field further, so that
eg responsibiliity for analysis lies "under" the tokenStreamValue()
method, but I think we should leave that for LUCENE-2309.  This is a
big enough change already...


> Decouple indexer from Document/Field impls
> ------------------------------------------
>
>                 Key: LUCENE-3177
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3177
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.0
>
>         Attachments: LUCENE-3177.patch
>
>
> I think we should define minimal iterator interfaces,
> IndexableDocument/Field, that indexer requires to index documents.
> Indexer would consume only these bare minimum interfaces, not the
> concrete Document/Field/FieldType classes from oal.document package.
> Then, the Document/Field/FieldType hierarchy is one concrete impl of
> these interfaces. Apps are free to make their own impls as well.
> Maybe eventually we make another impl that enforces a global schema,
> eg factored out of Solr's impl.
> I think this frees design pressure on our Document/Field/FieldType
> hierarchy, ie, these classes are free to become concrete
> fully-featured "user-space" classes with all sorts of friendly sugar
> APIs for adding/removing fields, getting/setting values, types, etc.,
> but they don't need substantial extensibility/hierarchy. Ie, the
> extensibility point shifts to IndexableDocument/Field interface.
> I think this means we can collapse the three classes we now have for a
> Field (Fieldable/AbstracField/Field) down to a single concrete class
> (well, except for LUCENE-2308 where we want to break out dedicated
> classes for different field types...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org