Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 35783 invoked from network); 20 Oct 2005 14:41:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Oct 2005 14:41:42 -0000 Received: (qmail 12354 invoked by uid 500); 20 Oct 2005 14:41:41 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 12326 invoked by uid 99); 20 Oct 2005 14:41:40 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2005 07:41:40 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [212.224.30.66] (HELO service-01.spree.de) (212.224.30.66) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2005 07:41:40 -0700 Received: from [172.16.1.19] (rio.spree.de [172.16.1.19]) (authenticated bits=0) by service-01.spree.de (8.13.4/8.13.4/Debian-3) with ESMTP id j9KEee46023677 for ; Thu, 20 Oct 2005 16:40:40 +0200 Message-ID: <4357ACA8.8010204@spree.de> Date: Thu, 20 Oct 2005 16:41:44 +0200 From: Michael Watzek Organization: Tech@Spree GmbH User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jdo-dev@db.apache.org Subject: Assertion A14.6-21 (Query.getFetchPlan) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi, assertion A14.6-21 specifies: "This method retrieves the fetch plan associated with the Query. It always returns the identical instance for the same Query instance. Any change made to the fetch plan affects subsequent query execution." I wonder, how the second part of this assertion can be tested. Does the following idea make sense: A class PC defines a fetch group A with post-load true. Class PC defines a postLoad callback which sets a transient field for each persistent field. The test case creates a query instance having candidate class PC. Afterwards, it retrieves the fetch plan, removes the default fetch group and adds fetch group A. Then, it executes the query. Finally, the test case checks for each returned query instance, if the transient fields which correspond with persistent fields of fetch group A have the right values. Would this work, or would the persistent field access in postLoad retrieve values from the database for non-loaded fields? Regards, Michael -- ------------------------------------------------------------------- Michael Watzek Tech@Spree Engineering GmbH mailto:mwa.tech@spree.de Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ -------------------------------------------------------------------