Return-Path: Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: (qmail 44762 invoked from network); 9 Oct 2006 22:02:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Oct 2006 22:02:01 -0000 Received: (qmail 83159 invoked by uid 500); 9 Oct 2006 22:01:54 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 82976 invoked by uid 500); 9 Oct 2006 22:01:54 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 82962 invoked by uid 99); 9 Oct 2006 22:01:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Oct 2006 15:01:54 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [208.97.132.202] (HELO spunkymail-a13.dreamhost.com) (208.97.132.202) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Oct 2006 15:01:53 -0700 Received: from [192.168.0.2] (adsl-074-229-189-244.sip.rmo.bellsouth.net [74.229.189.244]) by spunkymail-a13.dreamhost.com (Postfix) with ESMTP id 9589C129B34 for ; Mon, 9 Oct 2006 15:01:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <200610081255.35168.nicolas.lalevee@anyware-tech.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F793D18-59EB-42E8-96AC-FA7598CF33C7@apache.org> Content-Transfer-Encoding: 7bit From: Grant Ingersoll Subject: Re: FieldSelectorResult instance descriptions? Date: Mon, 9 Oct 2006 18:01:29 -0400 To: java-user@lucene.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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: java-user-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-user-help@lucene.apache.org > -------------------------- 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: java-user-unsubscribe@lucene.apache.org For additional commands, e-mail: java-user-help@lucene.apache.org