[
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
New patch, removing IndexableDocument so now we only have
IndexableField and IW accepts Iterable<? extends IndexableField> to
add/updateDocument.
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
this:
* 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
hierarchy.
* 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
create.
> 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, 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: [email protected]
For additional commands, e-mail: [email protected]
