lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: FieldSelectorResult instance descriptions?
Date Mon, 09 Oct 2006 22:01:29 GMT
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...

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  

> : 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:
> For additional commands, e-mail:

Grant Ingersoll
Sr. Software Engineer
Center for Natural Language Processing
Syracuse University
335 Hinds Hall
Syracuse, NY 13244

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message