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

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

+1

I think this is a great idea.

Having a clear separation from the 'core space' where the indexer sits, and the 
'user space' gives us the freedom to address the Document/Fieldable class stack 
problems.

We could introduce an IndexableDocument abstraction (which Document would 
implement) which provides the stripped down API that the indexer needs for 
Documents, which is just a way to get the fields to index and store. 

Given that the indexer need only know the name, type and value/tokenstream for 
a Field, we can visualize this as just a tuple.  Therefore the 
IndexableDocument, rather than returning Fields, could return instances of a 
new Tuple class, which would be immutable.  Field would then implement Tuple.

Document and Field would then be exactly as suggested, 'user space' app 
friendly mutable classes.  

On the search side, the 'core space' wouldn't know of the idea of a Document, 
but rather a set of tuples.  We would then allow different consumers of those 
tuples to be provided.  One such consumer would use the tuples to build 
Documents and Fields again. 

> 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-CleanField.patch, 
> LUCENE-2310-Deprecate-AbstractField.patch, 
> LUCENE-2310-Deprecate-AbstractField.patch, 
> LUCENE-2310-Deprecate-AbstractField.patch, 
> LUCENE-2310-Deprecate-DocumentGetFields-core.patch, 
> LUCENE-2310-Deprecate-DocumentGetFields.patch, 
> LUCENE-2310-Deprecate-DocumentGetFields.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

Reply via email to