lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Updated] (LUCENE-3177) Decouple indexer from Document/Field impls
Date Thu, 09 Jun 2011 17:47:58 GMT


Michael McCandless updated LUCENE-3177:

    Attachment: LUCENE-3177.patch

New patch, removing IndexableDocument so now we only have
IndexableField and IW accepts Iterable<? extends IndexableField> to

This breaks one Lucene core test (TestDocBoost), because indexer no
longer applies doc boost.

I'd like to cut a new branch, and commit this starting patch there.
I think (hopefully) the plan for the branch will be something like

  * Commit/iterate on this issue, which fully decouples indexer
    (oal.index.*) from our current
    Field/Fieldable/AbstractField/Document impl.  This gives
    LUCENE-2308 more freedom to make concrete "user space" classes.

  * Commit/iterate on LUCENE-2308, which collapses the *Field
    hierarchy to one concrete class, and adds FieldType

  * Maybe: do LUCENE-2309 (decouple analyzers from indexer).  This
    would mean IndexableField no longer needs isTokenized, nor the
    string/readerValue() methods.  Indexer would just ask for the
    tokenStream, and the doc/field impl would go and look at its flags
    like NOT_ANALYZED, etc., to figure out what token stream to

> Decouple indexer from Document/Field impls
> ------------------------------------------
>                 Key: LUCENE-3177
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.0
>         Attachments: LUCENE-3177.patch, 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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message