[jira] Commented: (LUCENE-778) Allow overriding a Document

["Nicolas Lalevée (JIRA)" <ji...@apache.org>]

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

Nicolas Lalevée commented on LUCENE-778:
----------------------------------------

Marker interface is a nice idea, but I think this will make Document handling more painfull. In my use case this will not be optimal.
In our application, we have a kind of workflow of Document. We have a big/master index which is holding every data on the system, and then we have specialized index which a part of the big one. The big one is for making big global queries on the whole data. The specialized are specialized for the end application. So the workflow is :
* from the raw data, make them as Document and index it in the master index
* for each specialized index :
** do the specific query on the master index
** from the retreived document, redecorate it with specialized indexed field
** index the decorated documents in the specialized index

Here I just have to decorate the Document retrieved form the master index. With incompatible interfaces, this won't be possible anymore. I will have to reinstanciate a Document each time and repopulate it.
So why not keep IndexWriter#addDocument(Document), and just change IndexReader#doc(int) to make it return a kind of DocumentWithOnlyStoredData, with DocumentWithOnlyStoredData extends Document. (the proposed named is horrible, I know !)


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