[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287136#comment-13287136
]
Chris Male commented on LUCENE-3312:
------------------------------------
bq. index.Document is an interface, I think for better extensibility in the
future it could be an abstract class - who knows what we will want to put there
in addition to the iterators...
I'm not sure that is such a big deal. But I do think should think about the
name here. We already have Document and it's going to become confusing with
two different Document classes kind of doing the same thing and with
document.Document implementing index.Document as well.
bq. previously we allowed one to remove fields from document by name, are we
going to allow this now separately for indexed and stored fields?
I think we need to simplify the document.Document API. I don't think it should
hold Indexable/StorableField instances but instead should just hold Field
instances. It is a userland kind of class and so is Field. We should make it
easy for people to add the Fields that they want. If they want to have a Field
which is both indexed and stored, then they can create it once and add it to
Document. If they want to do it separately, then they can do that too. Since
Field implements both IndexableField and StorableField, it can serve the dual
purpose.
That way the API in document.Document is pretty simple and you can add and
remove things as done in the past.
> Break out StorableField from IndexableField
> -------------------------------------------
>
> Key: LUCENE-3312
> URL: https://issues.apache.org/jira/browse/LUCENE-3312
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/index
> Reporter: Michael McCandless
> Assignee: Nikola Tankovic
> Labels: gsoc2012, lucene-gsoc-12
> Fix For: Field Type branch
>
> Attachments: lucene-3312-patch-01.patch, lucene-3312-patch-02.patch,
> lucene-3312-patch-03.patch, lucene-3312-patch-04.patch
>
>
> In the field type branch we have strongly decoupled
> Document/Field/FieldType impl from the indexer, by having only a
> narrow API (IndexableField) passed to IndexWriter. This frees apps up
> use their own "documents" instead of the "user-space" impls we provide
> in oal.document.
> Similarly, with LUCENE-3309, we've done the same thing on the
> doc/field retrieval side (from IndexReader), with the
> StoredFieldsVisitor.
> But, maybe we should break out StorableField from IndexableField,
> such that when you index a doc you provide two Iterables -- one for the
> IndexableFields and one for the StorableFields. Either can be null.
> One downside is possible perf hit for fields that are both indexed &
> stored (ie, we visit them twice, lookup their name in a hash twice,
> etc.). But the upside is a cleaner separation of concerns in API....
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
