[
https://issues.apache.org/jira/browse/LUCENE-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703407#action_12703407
]
Michael Busch commented on LUCENE-1597:
---------------------------------------
{quote}
Can we maybe rename Descriptor -> Type? Eg FieldDescriptor ->
FieldType?
{quote}
Done.
{quote}
Can a single FieldDescriptor be shared among many fields? Seems like
we'd have to take name out of FieldDescriptor (I don't think the name
should be in FieldDescriptor, anyway).
{quote}
I agree, this should be possible. I removed the name.
{quote}
NumericFieldAttribute seems awkward (one shouldn't have to turn on/off
zero padding, trie; or rather it's better to operate in "use cases"
like "I want to do range filtering" or "I want to sort"). Seems like
maybe we need a SortAttribute and RangeFilterAttribute
(or... something).
{quote}
Yep I agree. Some things in this prototype are quite goofy, because I
wanted to mainly demonstrate the main ideas. The attributes you suggest
make sense to me.
> 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
> Assignee: 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: [email protected]
For additional commands, e-mail: [email protected]
