> But I suppose for Document > has to be further subclassed so that the other > non-initialized fields can be obtained as well, or
I don't think Document would be the right place for this - as a design pattern it is cast as a "value object" or "transfer object" which is passed to (potentially remote) clients. It shouldn't be holding connections to an index so it can load extra fields on demand. Regardless, any "laziness" to the selective field loading will be hard to optimize when it is not possible to directly access an individual field on disk - the offsets are not stored and you have to serially read through all of the document's fields on disk until you reach the one you want. There's a price to pay for allowing clients too much freedom and I think lazy loading of field values is an example of something which is too costly. I personally prefer a search interface which requires clients to state up front what fields they want returned - the equivalent of SQL's "Select" clause in addition to the usual "where.." matching criteria. Cheers, Mark Send instant messages to your online friends http://uk.messenger.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]