[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
