A simple solution might be a 'classname' setup for the Document
creation - like the default Directory implementation uses. As long as
the subclass has a no-arg ctor it is trivial.
It might avoid a bit of object creation/copying.
On Jan 17, 2007, at 11:25 AM, Doug Cutting (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-778?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12465455 ]
Doug Cutting commented on LUCENE-778:
-------------------------------------
If we decide to make Document non-final, then we must document very
clearly the ways in which it may be subclassed, in particular that
instances returned from IndexReader.document() will not be of the
subclass.
Should we move this discussion to lucene-dev ?
Since Jira comments are sent to lucene-dev, I see no reason. The
mailing list may be more appropriate for discussing general,
process-related issues, but for specific technical issues, Jira is
usually better.
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.
-
If you think it was sent incorrectly contact one of the
administrators: https://issues.apache.org/jira/secure/
Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/
software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
