See http://www.gossamer-threads.com/lists/lucene/java-dev/33964?
search_string=Lazy%20Field%20Loading;#33964 for the discussion on
Java Dev from wayback if you want more background info.
To some extent, I still think Lazy Fields are in the early adopter
stage, since they haven't officially been released, so these
questions are good for vetting them. And there is still the question
of how to handle Document.getField() versus Document.getFieldable
()... but that is a discussion for the dev list.
See below for more...
HTH,
Grant
On Oct 9, 2006, at 5:22 PM, Chris Hostetter wrote:
: If you read the entire source as I did, I becomes clear ! :)
: The interesting code is in FieldsReader.
Not neccessarily. There can be differneces between how constants are
used and how they are suppose to be used (depending on wether or
not the
code using them has any bugs in it)
I will put some javadocs on these (or if someone wants to add a
patch...)
: NO_LOAD : skip the field, it's value won't be available
Should the client expecation for "NO_LOAD" fileds be that the
Document.getField/getFieldable will return will null, and that
the List returned by getFields() will not contain anything for these
fields, or should clients assume there may be an "empty" Fieldable
object
returned by any of these methods (or included in the list)
My understanding is in the NO_LOAD case, doc.add(Field) is not
called, so Document.getField() will return null. Again, I will try
to get some javadocs on this part.
: LAZY_LOAD : do not load the field value, but if you request it
later, it will
: be loaded on request. Note that it can be lazy-loaded only if the
reader is
: still opened.
What should clicents expected to happen if the reader has already been
closed?
Search the dev list for "Semantics of a closed IndexInput" for some
discussion on this between Doug and I. Unfortunately, the answer
isn't all that satisfying, since it is undefined. I would prefer
better treatment than that, but it isn't obvious. I originally
thought there would be an exception to catch or something (in fact,
my original test cases had expected it to be handled), but ended up
putting the handling on the application, since the app should know
when it has been closed.
: LOAD_FOR_MERGE : internal use when merging segments: it avoids
uncompressing
: and recompressing data, the data is merged "binarily".
this seems like a second-class citizen then correct? not intende for
client code to use in their FieldSelector ? ... so what if the do use
it? ... can they expect the data n the Field object to be
uncompressed on
the fly if they attempt to access it later?
I would agree it is a second-class citizen, but maybe Otis can add
his thoughts, as I think he added this feature. I am unsure of the
results of using it outside of the merge scope.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Grant Ingersoll
Sr. Software Engineer
Center for Natural Language Processing
Syracuse University
335 Hinds Hall
Syracuse, NY 13244
http://www.cnlp.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
