lucene-dev mailing list archives

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

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


Mime
View raw message