[
https://issues.apache.org/jira/browse/LUCENE-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478169
]
Hoss Man commented on LUCENE-778:
---------------------------------
> 1) it does matter from the user point of view : we cannot do anymore
> writer.addDocument(reader.doc(10)).
...and i argue that is precisely what we want ... it's not generally safe for
people do do that now, but becuase it is so easy, they think they can. If we
change the API so that doc(int) doesn't return the same class that addDocument
takes we make go out of their way a little bit and need to write something
like...
writer.addDocument(new ReIndexedDocument(reader.doc(10)));
...where the RedIndexedDocument class can have some good javadocs explaining
what it is, when to use it, and most importantly: when it doesn't work.
> 2) Effectively I can implement a DecoratedDocument. But I cannot make Lucene
> instanciating my own document, the
...i'm still not clear why you feel you need lucene to instantiate your
specific class ... why wouldn't a decorator class work for the use case you
describe?
public class YourDocumentWraper implements IndexableDocument {
public YourDocumentWraper(ReturnableDocument r, Object specialStuff) {
...
}
public Fieldable getFieldable(String f) {
// ...check if you want special stuff, if not...
return r.getFieldable(f);
}
}
> 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]
