Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 1 Jun 2012 12:47:24 +0000 (UTC)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <113313092.26436.1338554844940.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <146451556.12961.1310639459816.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (LUCENE-3312) Break out StorableField from
 IndexableField
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287364#comment-13287364 ] 

Michael McCandless commented on LUCENE-3312:
--------------------------------------------

I think I like this decoupling ... for normal users I don't think this
makes the API harder?  They still work with TextField, FloatField,
StoredField, etc.?  It's just that, under the hood, these sugar classes
extend from the right base class (indexed or stored).

Document.add is just type overloaded, but Document.get* will get
messier: we'll need getStored and getIndexed?  I guess that would be
simpler if Document could just store Field instances... hmm.

It would also be less invasive change for migrating from 4.0 -> 5.0
(assuming this issue is done only for 5.0...) if we didn't do the hard
split.... else we need a back-compat story...

{quote}
bq. We already have Document and it's going to become confusing with two different Document classes

+1 to use a better name (LuceneDocument? AbstractDocument?).
{quote}

Maybe IndexDocument?  I think it's OK as an interface if we mark it
@lucene.internal?  This is the raw, super expert low-level that indexer
uses to consume documents... it has only 2 methods, and I think for
expert users it could be a hassle if we force the impl to inherit from
our base class...

Should StoredDocument (returned from IR.document) be "read only"?  Like
you can iterate its fields, look them up, etc., but not eg remove them?

We should probably rename document.Field -> document.IndexedField and
document.Field -> document.IndexedFieldType?

Also I think we should rename XXXField.TYPE_UNSTORED -> .TYPE, since in
each case there's only 1 TYPE instance for that sugar field?

Separately, I think even for 4.0 we should remove XXXField.TYPE_STORED
from all the sugar fields (TextField, StringField, etc.); expert users
can always make a custom Indexable/Storable/Field/FieldType that both
stores & indexes...

                
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org