: 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) : 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) : 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? : 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? -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
