[
https://issues.apache.org/jira/browse/LUCENE-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478532
]
Hoss Man commented on LUCENE-778:
---------------------------------
Grant: I have no serious objection to making Document non-final ... i was just
pointing out that as long as we are mucking with the Document related APIs,
this may be a good time to solve the perception issue people have with what a
"Document" is ... that single container class gets used in two very different
ways, and clarifying what those ways are with seperate Interfaces would be
useful. from a more parcticle standpoint, if i want to subclass Document and
add custom behavior, what methods impact the way a document gets indexed? what
methods impact the behavior of returned data? ... the answers to thouse
questions aren't obvious to most novice users as is -- but we tend to punt on
them since no one can "replace" a Document instance at the moment ... we'd need
to be more clear about that if subclassing is allowed and DocumentFactories or
passing empty Beans to IndexReader.document start being allowed.
regarding your specific question about...
public void document(int n, Document doc)
...i'm leary of that approach just because of all the places people might want
it ... with FieldSelector or without; from a Searcher, or an IndexReader, or a
Hits instance, etc...
I'd be more in favor of adding a "setDocumentFactory" method on IndexReader or
something like that if we went that route ... but as i said, if Document (or
whatever interface/abstract class we make IndexReader.document return) isn't
final, then it's not clera to me why a Decorator model wouldn't be good enough.
> 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]
