lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2310) Reduce Fieldable, AbstractField and Field complexity
Date Tue, 16 Mar 2010 09:20:27 GMT

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

Chris Male commented on LUCENE-2310:
------------------------------------

Hi Shai,

{quote}
i like the idea of Document to implement Iterable, but how does that solve the case where
someone wants to query how many fields a document has?
{quote}

It doesn't, but then I'd add a numFields() method maybe.  It seems like something with a small
use case and so having it has a method on the side seems ideal.

{quote}
Will you still have getFields(), only now it will return an unmodifiable collection?
{quote}

Yes and no.  getFields will remain but with a modifiable list.  I will then deprecate the
method and recommend people use the Iterable.  This gives everybody a chance to migrate during
the 3.x versions.

{quote}
Maybe just do: (1) Doc implements Iterable and (2) Doc exposes numFIelds(), add(Field)?
{quote}

Yup lets do that.  Unfortunately getFields will remain until 4.0.

{quote}
About remove(field), I thought of a possible scenario though I still don't think it's interesting
enough - suppose that you pass your Document through a processing pipeline/chain, each handler
adds fields as metadata to the Document. For example, annotators. It might be that a field
A exists, only for a handler down the chain to understand A's meaning and then replace it
w/ A1 and A2. For that you'll want to be able to move a field ... I guess we could add a remove
method to Document, and if it'll be called while the fields are iterated on, a CME will be
thrown, which is perfectly fine with me.
{quote}

With the idea of having remove(...) I am trying to foresee what people might be doing via
getFields() and thus are not going to be able to do when its gone.  We will have the ability
to add and iterate, so having the functionality to remove seems to complete it.  I completely
agree that if something happens and a CME is thrown, then that problem should be left to the
user.

I think this clarifies this direction.  Document will be changed as follows:
- Document will become Iterable<Fieldable>
- getFields() will be deprecated in favour of the Iterable
- numFields() will be added returning the number of fields
- remove(String) will be added allowing someone to remove Fields with the given name.  If
a CME occurs, thats up to the user to handle.

Cheers Shai!



> Reduce Fieldable, AbstractField and Field complexity
> ----------------------------------------------------
>
>                 Key: LUCENE-2310
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2310
>             Project: Lucene - Java
>          Issue Type: Sub-task
>          Components: Index
>            Reporter: Chris Male
>         Attachments: LUCENE-2310-Deprecate-AbstractField.patch, LUCENE-2310-Deprecate-AbstractField.patch,
LUCENE-2310-Deprecate-AbstractField.patch
>
>
> In order to move field type like functionality into its own class, we really need to
try to tackle the hierarchy of Fieldable, AbstractField and Field.  Currently AbstractField
depends on Field, and does not provide much more functionality that storing fields, most of
which are being moved over to FieldType.  Therefore it seems ideal to try to deprecate AbstractField
(and possible Fieldable), moving much of the functionality into Field and FieldType.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message