Return-Path: 
 <jdo-dev-return-4594-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org>
Delivered-To: apmail-db-jdo-dev-archive@www.apache.org
Received: (qmail 17142 invoked from network); 9 Jun 2006 01:11:28 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 9 Jun 2006 01:11:28 -0000
Received: (qmail 47037 invoked by uid 500); 9 Jun 2006 01:11:28 -0000
Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:jdo-dev-help@db.apache.org>
List-Unsubscribe: <mailto:jdo-dev-unsubscribe@db.apache.org>
List-Post: <mailto:jdo-dev@db.apache.org>
List-Id: <jdo-dev.db.apache.org>
Reply-To: jdo-dev@db.apache.org
Delivered-To: mailing list jdo-dev@db.apache.org
Received: (qmail 47016 invoked by uid 99); 9 Jun 2006 01:11:27 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jun 2006 18:11:27 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=HTML_MESSAGE,UNPARSEABLE_RELAY
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [192.18.42.249] (HELO nwkea-pix-1.sun.com) (192.18.42.249)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jun 2006 18:11:26 -0700
Received: from d1-sfbay-01.sun.com ([192.18.39.111])
	by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k591B5LO021512
	for <jdo-dev@db.apache.org>; Thu, 8 Jun 2006 18:11:05 -0700 (PDT)
Received: from conversion-daemon.d1-sfbay-01.sun.com by d1-sfbay-01.sun.com
 (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
 id <0J0K00H01IETXX00@d1-sfbay-01.sun.com>
 (original mail from Craig.Russell@Sun.COM) for jdo-dev@db.apache.org; Thu,
 08 Jun 2006 18:11:05 -0700 (PDT)
Received: from [192.168.0.10] (c-24-6-172-77.hsd1.ca.comcast.net
 [24.6.172.77])
 by d1-sfbay-01.sun.com
 (Sun Java System Messaging Server 6.2-4.02 (built Sep  9 2005))
 with ESMTPSA id <0J0K00FJVJAGRP00@d1-sfbay-01.sun.com> for
 jdo-dev@db.apache.org; Thu, 08 Jun 2006 18:11:04 -0700 (PDT)
Date: Thu, 08 Jun 2006 18:11:02 -0700
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Behavior of projection queries (long)
Sender: Craig.Russell@Sun.COM
To: JDO Expert Group <jdo-experts-ext@Sun.COM>,
        Apache JDO project <jdo-dev@db.apache.org>
Message-id: <6DC3CBE5-203B-4DB0-AF08-4CBBCBA4B17E@SUN.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.750)
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-20--290428351; micalg=sha1
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

--Apple-Mail-20--290428351
Content-Type: multipart/alternative;
	boundary=Apple-Mail-19--290428901


--Apple-Mail-19--290428901
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Javadogs,

For the JDO maintenance release, we have to decide what the behavior  
is for projection queries of various kinds of fields. [There are no  
TCK tests for this behavior.] Consider this class:

class Company {
int id;
String symbol;
Date incorporated;
BigDecimal revenues;
Set<Department> departments;
Locale hqLocale;
Integer empCount;
Address hqAddress;
}

and these JDOQL queries:

Collection<DTOCompany> dtos = execute this query: "SELECT new  
DTOCompany(symbol, incorporated, revenues, departments, hqLocale,  
empCount, hqAddress) FROM Company ORDER BY id"

Collection<Company> cos = execute this query: "SELECT FROM Company  
ORDER BY id"

1. Now, iterate the collections of dtos and cos. For each  
corresponding result dto and co in the collection of results:

For each of symbol, incorporated, revenues, departments, hqLocale,  
empCount, and hqAddress:

Does dto.symbol == co.symbol?
Does dto.symbol.equals(co.symbol)?

2. Now, suppose I change the mutable second class fields of the  
instances I get from cos (the persistent instances).

tx.begin();
cos.incorporated.setTime(new Date().getMillis());
tx.commit();

tx.begin();
cos.departments.add(new Department());
tx.commit();

tx.begin();
cos.hqAddress.setState("CA");
tx.commit();

Have I modified the company instance in the database in any of these  
cases?

3.Now, suppose I change the mutable second class fields of the  
instances I get from dtos (the holders for the field values of the  
instances).

tx.begin();
dtos.incorporated.setTime(new Date().getMillis());
tx.commit();

tx.begin();
dtos.departments.add(new Department());
tx.commit();

tx.begin();
dtos.hqAddress.setState("CA");
tx.commit();

Have I modified the company instance in the database in any of the  
cases?

Here's a proposal to clarify the specification.

If mutable second class fields are selected by a projection query,  
the instances returned by the query are the instances of the owning  
first class instance. Changes made to the results are reflected in  
the database at transaction commit. There is no requirement that  
immutable fields returned by a projection query are identical to  
corresponding fields in cached instances.

The implication is that a projection query that selects mutable  
second class fields has the effect of instantiating the owning first  
class instance and associating the mutable second class fields in the  
query result with the owning first class instance. So selecting first  
name, last name, age, and ssn returns only values not associated with  
persistent instances. But selecting incorporated, departments, or  
hqAddress will instantiate the first class instances and its default  
fetch group.

  Craig

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


--Apple-Mail-19--290428901
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Javadogs,<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>For the JDO maintenance =
release, we have to decide what the behavior is for projection queries =
of various kinds of fields. [There are no TCK tests for this behavior.] =
Consider this class:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>class Company =
{</DIV><DIV>int id;</DIV><DIV>String symbol;</DIV><DIV>Date =
incorporated;</DIV><DIV>BigDecimal =
revenues;</DIV><DIV>Set&lt;Department&gt; departments;</DIV><DIV>Locale =
hqLocale;</DIV><DIV>Integer=A0empCount;</DIV><DIV>Address =
hqAddress;</DIV><DIV>}</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>and these JDOQL =
queries:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Collection&lt;DTOCompany&gt; =
dtos =3D execute this query: "SELECT new DTOCompany(symbol, =
incorporated, revenues, departments, hqLocale, empCount, hqAddress) FROM =
Company ORDER BY id"</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Collection&lt;Company&gt; =
cos =3D execute this query: "SELECT FROM Company ORDER BY =
id"</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>1. Now, =
iterate the collections of dtos and cos. For each corresponding result =
dto and co in the collection of results:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>For each of symbol, =
incorporated, revenues, departments, hqLocale, empCount, and =
hqAddress:</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>Does=
 dto.symbol =3D=3D co.symbol?</DIV><DIV>Does =
dto.symbol.equals(co.symbol)?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>2. Now, suppose I change =
the mutable second class fields of the instances I get from cos (the =
persistent instances).</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>tx.begin();</DIV><DIV>cos.inc=
orporated.setTime(new =
Date().getMillis());</DIV><DIV>tx.commit();</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>tx.begin();</DIV><DIV>cos.dep=
artments.add(new Department());</DIV><DIV>tx.commit();</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>tx.begin();</DIV><DIV>cos.hqA=
ddress.setState("CA");</DIV><DIV>tx.commit();</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Have I modified the company =
instance in the database in any of these cases?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>3.Now, suppose I change the =
mutable second class fields of the instances I get from dtos (the =
holders for the field values of the =
instances).<DIV>=A0</DIV><DIV>tx.begin();</DIV><DIV>dtos.incorporated.setT=
ime(new Date().getMillis());</DIV><DIV>tx.commit();</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>tx.begin();</DIV><DIV>dtos.de=
partments.add(new Department());</DIV><DIV>tx.commit();</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>tx.begin();</DIV><DIV>dtos.hq=
Address.setState("CA");</DIV><DIV>tx.commit();</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Have I modified the company =
instance in the database in any of the cases?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>Here's a proposal to clarify the =
specification.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>If mutable second class =
fields are selected by a projection query, the instances returned by the =
query are the instances of the owning first class instance. Changes made =
to the results are reflected in the database at transaction commit. =
There is no requirement that immutable fields returned by a projection =
query are identical to corresponding fields in cached =
instances.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>The =
implication is that a projection query that selects mutable second class =
fields has the effect of instantiating the owning first class instance =
and associating the mutable second class fields in the query result with =
the owning first class instance. So selecting first name, last name, =
age, and ssn returns only values not associated with persistent =
instances. But selecting incorporated, departments, or hqAddress will =
instantiate the first class instances and its default fetch =
group.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>=A0Craig</DIV><DIV><BR><DIV> =
<P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Craig Russell</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Architect, Sun Java =
Enterprise System <A =
href=3D"http://java.sun.com/products/jdo">http://java.sun.com/products/jdo=
</A></FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">408 =
276-5638 <A =
href=3D"mailto:Craig.Russell@sun.com">mailto:Craig.Russell@sun.com</A></FO=
NT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">P.S. A =
good JDO? O, Gasp!</FONT></P>  </DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-19--290428901--

--Apple-Mail-20--290428351
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICEB7Y7fLHmKoeHTUdbtYrvpAwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxNTIxNDc0NFoXDTA2MTIxNTIxNDc0
NFowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMXXgEAm88nu8cFbxXSWqTq+GaYpCx/0QSom
8kBbVxpJIURuO4ErLDupeXu6y9+5e7ZKLbeSQE5xbfYPcQR/IhqmYKy5YqRcuzPXREBj2zKEkZph
pNXWpHgMdx9W8dq0Cu2i9Ux/S6c2MuEHrP6gfGGll+b/mzLoO280QHTuE4pcpKntRnwZdGxQ/5l8
IL+eLP+jpJAbYW9C+KNKofZtS6V6R0uzlqTOsEdZvwxZQ4mmPgHoz1+Gjwme/PC5sKvF09MaJDiI
pj9SvZ4CTCgcDZV78J086YwlVbMC0VQotjhu1p42lr8CS33IXLz3OWNrDETCAepah/Dgw2ZZApQ9
9L0CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEEBQADgYEAKdIkgAWCg2Bi7ocnstfJA4iymTRI2/L4oQx9zvllM9bNJ2cR
cecJIx3HuoHbhPvemh1GExEPgHU+dXSxDmD0BEmPnhSReKCURyslnbMphPZ5kR6USzQFrRa+v0ii
J+SBO9VQYTQWT+xEjmRLM76MfkBFw3IOC9CUkRoYZ88pOoUwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEB7Y7fLHmKoeHTUdbtYrvpAwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNjA5MDExMTAzWjAjBgkqhkiG9w0B
CQQxFgQUXNKeW6dRBrDGCMHDC1G7x0Zx4PgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe2O3yx5iqHh01HW7WK76QMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe
2O3yx5iqHh01HW7WK76QMA0GCSqGSIb3DQEBAQUABIIBAJ3ujEcO/9XmACBEnhOqAsKjFqEXJOK2
9P1fSlJCkNcqvbgBKPUfPO4MPTgi8IoIFKd0wMd6BfzjOT5SRE9//BTOFL0fZ9sNuCTC6MJsJxbg
/QK84iU1aEbGCirfihzwzTE+TKPAfhYl0Dfza3EfikseHO1CELwWTNIoPJBK7nB7o+Jl18JgrQcE
pNvJz3g0+F9Y6pw5M5ifOimN0LSA4qJdEwRAdgPTsx8km4zlMpKrfB7xhunsLSvM6ZSzze1tKrl3
f6baaa9mG9FCvppedX0rqUhHeGdHZEeLsY95qsQ4ZayYzgG4D4ladHKLHI6ui+qk4v226NkC3BfM
ur7tl1gAAAAAAAA=

--Apple-Mail-20--290428351--