Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <22413000.1159188652406.JavaMail.jira@brutus>
Date: Mon, 25 Sep 2006 05:50:52 -0700 (PDT)
From: "Grant Ingersoll (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-662) Extendable writer and reader of
 field data
In-Reply-To: <19231794.1156264813957.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

    [ http://issues.apache.org/jira/browse/LUCENE-662?page=3Dcomments#actio=
n_12437543 ]=20
           =20
Grant Ingersoll commented on LUCENE-662:
----------------------------------------

Haven't looked fully at the patch, but one thing I am curious about is why =
remove the Fieldable interface?

> Extendable writer and reader of field data
> ------------------------------------------
>
>                 Key: LUCENE-662
>                 URL: http://issues.apache.org/jira/browse/LUCENE-662
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Store
>            Reporter: Nicolas Lalev=C3=A9e
>            Priority: Minor
>         Attachments: generic-fieldIO-2.patch, generic-fieldIO.patch
>
>
> As discussed on the dev mailing list, I have modified Lucene to allow to =
define how the data of a field is writen and read in the index.
> Basically, I have introduced the notion of IndexFormat. It is in fact a f=
actory of FieldsWriter and FieldsReader. So the IndexReader, the indexWrite=
r and the SegmentMerger are using this factory and not doing a "new FieldsR=
eader/Writer()".
> I have also introduced the notion of FieldData. It handles every data of =
a field, and also the writing and the reading in a stream. I have done this=
 way because in the current design of Lucene, Fiedable is an interface, so =
methods with a protected or package visibility cannot be defined.
> A FieldsWriter just writes data into a stream via the FieldData of the fi=
eld.
> A FieldsReader instanciates a FieldData depending on the field name. Then=
 it use the field data to read the stream. And finnaly it instanciates a Fi=
eld with the field data.
> About compatibility, I think it is kept, as I have writen a DefaultIndexF=
ormat that provides some DefaultFieldsWriter and DefaultFieldsReader. These=
 implementations do the exact job that is done today.
> To acheive this modification, some classes and methods had to be moved fr=
om private and/or final to public or protected.
> About the lazy fields, I have implemented them in a more general way in t=
he implementation of the abstract class FieldData, so it will be totally tr=
ansparent for the Lucene user that will extends FieldData. The stream is ke=
pt in the fieldData and used as soon as the stringValue (or something else)=
 is called. Implementing this way allowed me to handle the recently introdu=
ced LOAD_FOR_MERGE; it is just a lazy field data, and when read() is called=
 on this lazy field data, the saved input stream is directly copied in the =
output stream.
> I have a last issue with this patch. The current design allow to read an =
index in an old format, and just do a writer.addIndexes() into a new format=
. With the new design, you cannot, because the writer will use the FieldDat=
a.write provided by the reader.
> enjoy !

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org