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