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

Hoss Man commented on LUCENE-778:
---------------------------------

1) from a design standpoint, as long as IndexReader/IndexSearcher deal with 
documents using a different interface name i nthe signature then IndexWriter, 
it doens't really matter what name is used -- what i suggested tackles a second 
point: keeping the existing interface backwards compatible for the forseeable 
future while migrating to this modified API.

2) if you are already decorating the docs you get back from your "master index" 
before adding them to your specialized indexes, then nothing i described would 
prevent that from continuing to work ... the bulk of your code could be example 
the same, you would just need a simple DecoratedDocument which impliments 
IndexableDocument and wraps a ReturnableDocument.

something like that might even be a common enough use case to inlcude in the 
core ... anyone with a legitimate use cases for doing round trips could use it 
as well.

> 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