[
https://issues.apache.org/jira/browse/LUCENE-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845702#action_12845702
]
Shai Erera commented on LUCENE-2310:
------------------------------------
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? Will you
still have getFields(), only now it will return an unmodifiable collection?
I guess the unmod collection can be returned even today, right?
BTW, what happens if getFields() return an unmod collection, but someone calls
doc.add(Field)? I think the unmod collection prevents you from adding to that
collection wrapper, but not for that collection to be changed from under the
hood? If that's true, then that could cause some trouble ... so getFields()
will really return a snapshot of Document, which means we need to clone Fields
...
Gets too complicated no? Maybe just do: (1) Doc implements Iterable and (2) Doc
exposes numFIelds(), add(Field)?
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.
> 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
