[
https://issues.apache.org/jira/browse/LUCENE-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703391#action_12703391
]
Michael Busch commented on LUCENE-1597:
---------------------------------------
{quote}
How would you turn on/off [future] CSF storage? A separate attr? A
boolean on StoreAttribute?
{quote}
I was thinking about adding a separate attribute. But here is one
thing I haven't figured out yet: it should actually be perfectly fine
to store a value in a CSF and *also* in the 'normal' store. The
problem is that the type of data input is the limiting factor here: if
the user provides the data as a byte array, then everything works
fine. However, if the data is provide as a Reader, then it's not
guaranteed that the reader can be read more than once. To implement
reset() is optional, as the javadocs say.
So maybe we should state in our javadocs that a reader must support
reset(), otherwise writing the data into more than one data structures
will result in an undefined behavior? Alternatively we could introduce
a new class called ResetableReader, where reset() is abstract, and
change the API in 3.0 to only accept that type of reader?
Btw. the same is true for fields that provide the data as a
TokenStream.
> 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
