[
https://issues.apache.org/jira/browse/LUCENE-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703367#action_12703367
]
Michael Busch commented on LUCENE-1597:
---------------------------------------
Thanks for the thorough review, Mike. Reading your response made me really
excited, because you exactly understood most of the thoughts I put into this
code, without me even mentioning them :) Thanks for writing them down!
I started including your suggestions into my patch and will reply with more
detail to your individual points as I'm working on them.
> New Document and Field API
> --------------------------
>
> Key: LUCENE-1597
> URL: https://issues.apache.org/jira/browse/LUCENE-1597
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index
> Reporter: Michael Busch
> Priority: Minor
> Attachments: lucene-new-doc-api.patch
>
>
> This is a super rough prototype of how a new document API could look like.
> It's basically what I came up with during a long flight across the Atlantic :)
> It is not integrated with anything yet (like IndexWriter, DocumentsWriter,
> etc.) and heavily uses Java 1.5 features, such as generics and annotations.
> The general idea sounds similar to what Marvin is doing in KS, which I found
> out by reading Mike's comments on LUCENE-831, I haven't looked at the KS API
> myself yet.
> Main ideas:
> - separate a field's value from its configuration; therefore this patch
> introduces two classes: FieldDescriptor and FieldValue
> - I was thinking that in most cases the documents people add to a Lucene
> index look alike, i.e. they contain mostly the same fields with the same
> settings. Yet, for every field instance the DocumentsWriter checks the
> settings and calls the right consumers, which themselves check settings and
> return true or false, indicating whether or not they want to do something
> with that field or not. So I was thinking we could design the document API
> similar to the Class<->Object concept of OO-languages. There a class is a
> blueprint (as everyone knows :) ), and an object is one instance of it. So in
> this patch I introduced a class called DocumentDescriptor, which contains all
> FieldDescriptors with the field settings. This descriptor is given to the
> consumer (IndexWriter) once in the constructor. Then the Document "instances"
> are created and added via addDocument().
> - A Document instance allows adding "variable fields" in addition to the
> "fixed fields" the DocumentDescriptor contains. For these fields the
> consumers have to check the field settings for every document instance (like
> with the old document API). This is for maintaining Lucene's flexibility that
> everyone loves.
> - Disregard the changes to AttributeSource for now. The code that's worth
> looking at is contained in a new package "newdoc".
> Again, this is not a "real" patch, but rather a demo of how a new API could
> roughly work.
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
