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