Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <26578418.1173131450774.JavaMail.jira@brutus>
Date: Mon, 5 Mar 2007 13:50:50 -0800 (PST)
From: "Hoss Man (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-778) Allow overriding a Document
In-Reply-To: <6787992.1169025027540.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

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 f=
or 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 ad=
dDocument 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 explainin=
g 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 Luc=
ene
> instanciating my own document, the=20

...i'm still not clear why you feel you need lucene to instantiate your spe=
cific class ... why wouldn't a decorator class work for the use case you de=
scribe?

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=C3=A9e
>            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 w=
ith 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 ap=
plication, ie some MyAppDocument and MyOtherAppDocument which have a proper=
ty holding a real Lucene Document. Then, when MyApp or MyOtherApp want to u=
se our generic lucene API, we have to "get out" the Lucene document, ie do =
some genericLuceneAPI.writeDoc(myAppDoc.getLuceneDocument()). This work fin=
e, 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 w=
ill allow more object-oriented code.

--=20
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