[ 
https://issues.apache.org/jira/browse/LUCENE-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478193
 ] 

Grant Ingersoll commented on LUCENE-778:
----------------------------------------

I feel like I'm missing something in this discussion, but couldn't we just make 
Document non-final and add:

public void document(int n, Document doc)

or even mark it as expert and call it populateDocument(int n, Document doc) or 
something like that

The semantics of which are to add the fields for document n to the Document 
object doc.  

>From the looks of the code, most of the Readers first thing in the document 
>call is: Document result = new Document()  so it is not like we are doing some 
>complicated construction that is optimized for the different types of readers.





> Allow overriding a Document
> ---------------------------
>
>                 Key: LUCENE-778
>                 URL: https://issues.apache.org/jira/browse/LUCENE-778
>             Project: Lucene - Java
>          Issue Type: New Feature
>    Affects Versions: 2.0.0
>            Reporter: Nicolas Lalevée
>            Priority: Trivial
>
> In our application, we have some kind of generic API that is handling how we 
> are using Lucene. The different other applications are using this API with 
> different semantics, and are using the Lucene fields quite differently. We 
> wrote some usefull functions to do this mapping. Today, as the Document class 
> cannot be overriden, we are obliged to make a document wrapper by 
> application, ie some MyAppDocument and MyOtherAppDocument which have a 
> property holding a real Lucene Document. Then, when MyApp or MyOtherApp want 
> to use our generic lucene API, we have to "get out" the Lucene document, ie 
> do some genericLuceneAPI.writeDoc(myAppDoc.getLuceneDocument()). This work 
> fine, but it becomes quite tricky to use the other function of our generic 
> API which is genericLuceneAPI.writeDocs(Collection<Document> docs).
> I don't know the rational behind making final Document, but removing it will 
> allow more object-oriented code.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to