Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 13 Jan 2006 15:10:19 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: [IMPORTANT] Fetch-depth
Sender: Craig.Russell@Sun.COM
To: JDO Expert Group <jdo-experts-ext@Sun.COM>,
        Apache JDO project <jdo-dev@db.apache.org>
Message-id: <087EE822-9BF6-47EB-B6F5-F3E49B8C9688@Sun.COM>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-6--27170221; micalg=sha1

--Apple-Mail-6--27170221
Content-Type: multipart/alternative;
	boundary=Apple-Mail-5--27170717


--Apple-Mail-5--27170717
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	delsp=yes;
	format=flowed

Javadogs,

I've spent some time looking at the semantics of fetch-depth and now =20
agree with the critics of the change that I proposed back in the =20
infamous October 1, 2005 message to the expert group subject: Re: =20
JDO2 =A712.7.2: fetch-depth only for "recursive fetch group =
references"?.

I now believe it's impractical to use fetch-depth to mean the maximum =20=

depth of the object graph reachable from the root object(s) field =20
because of several messages sent on the subject by Joerg von =20
Frantzuis, Alexander Bieber, and Marco Schultz.

Briefly, the argument is that if fetch-depth limits the number =20
absolutely, then it's not possible easily to use the fetch-group to =20
add another field to a fetch plan simply by adding a fetch-group that =20=

includes that field. Instead, a new fetch-group that changes the =20
fetch-depth must be used. And each new use-case needs to provide a =20
different fetch-depth number if another level of fetching is desired.

I believe that the use of fetch-group to determine whether fields =20
(navigating relationships) are fetched should be natural, and that we =20=

should therefore use fetch-depth for its original purpose of limiting =20=

recursion.

If you disagree with this position, please reply so we can move =20
forward and define the use of fetch-depth for recursion (as in the =20
original semantics of the attribute).

Thanks,

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-5--27170717
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>I've spent some time =
looking at the semantics of fetch-depth and now agree with the critics =
of the change that I proposed back in the infamous October 1, 2005 =
message to the expert group subject:=A0<B>Re: JDO2 =A712.7.2: =
fetch-depth only for "recursive fetch group =
references"?</B>.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I now believe it's =
impractical to use fetch-depth to mean the maximum depth of the object =
graph reachable from the root object(s) field because of several =
messages sent on the subject by Joerg von Frantzuis, Alexander Bieber, =
and Marco Schultz.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Briefly, the argument is =
that if fetch-depth limits the number absolutely, then it's not possible =
easily to use the fetch-group to add another field to a fetch plan =
simply by adding a fetch-group that includes that field. Instead, a new =
fetch-group that changes the fetch-depth must be used. And each new =
use-case needs to provide a different fetch-depth number if another =
level of fetching is desired.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I believe that the use of =
fetch-group to determine whether fields (navigating relationships) are =
fetched should be natural, and that we should therefore use fetch-depth =
for its original purpose of limiting recursion.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>If you disagree with this =
position, please reply so we can move forward and define the use of =
fetch-depth for recursion (as in the original semantics of the =
attribute).</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Thanks,</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Craig</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-5--27170717--

--Apple-Mail-6--27170221
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMTEzMjMxMDE5WjAjBgkqhkiG9w0B
CQQxFgQUJHEaZBbnz2YB2WiITfpqjKFFrq0wgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe2O3yx5iqHh01HW7WK76QMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe
2O3yx5iqHh01HW7WK76QMA0GCSqGSIb3DQEBAQUABIIBAF01aU8vzloW7A53Qjtkh/yR4A20bGLJ
Th12Q2olDlCuhWh2Zar8UMO2yXtUOkN9OsqcJtIUQoytwdPvmndg71FvfdsRv5gkQGY6iIiHVhaU
TUGes9TOWTvdBhUcGN1mY6BaLD/tFidk+yZMAm/gwUDkxX8VPBqP9+UB10FjK8aa+zaoasoi/grQ
0RHuaW1wjO6jlBg7QAX/Z8wBn8mIYx4EOIKYnuAcRnpbxkbR/AfyuHB1lzFdKf34rNIDxyN14M/5
niboALiTk5Uqlls0Mr8yT8zO66Z57ftkeZ26MuxdmQGsnHmAAgz9zLp0TC5gORsDY+h7clI6fc75
K763k0MAAAAAAAA=

--Apple-Mail-6--27170221--