[jira] Commented: (LUCENE-778) Allow overriding a Document

["Hoss Man (JIRA)" <ji...@apache.org>]

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

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

>From email...

http://www.nabble.com/-jira--Created%3A-%28LUCENE-778%29-Allow-overriding-a-Document-tf3026011.html

: 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.

a differnet tack on the topic: there is really no good reason why the
"Document" class used for indexing data should be the same as the
"Document" classs ued for returning results ... using the same class in
this way results in all sort of confusio abotu which methods can be called
in which context, and frequently leads people to assume they can do safe
"round trips" of their Documents ... doing a search, modifying a field
value, and then re-inexing it -- not considering what happens to
non-STOREd fields or field/document boosts.

any work done to change the Document API to make it easier to subclass
should probably start with a seperation of these too completley different
concepts.

One approach off the top of my head: make an IndexableDocument interface
for clients to pass to IndexWriter and a "ReturnableDocument" class for
IndexReader/IndexSearcher to return ... the existing Document class can
subclass ReturnableDocument and impliment IndexableDocument, the existing
methods with Document in their sig would be deprecated and replaced with
methods using one of these new class names

...some followup comments can be found in the thread archive.


> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org