Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 29868 invoked from network); 20 Jul 2005 22:25:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Jul 2005 22:25:54 -0000 Received: (qmail 45632 invoked by uid 500); 20 Jul 2005 22:25:54 -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 45619 invoked by uid 99); 20 Jul 2005 22:25:54 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Jul 2005 15:25:54 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=HTML_60_70,HTML_MESSAGE,HTML_OBFUSCATE_05_10 X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.98.34] (HELO brmea-mail-3.sun.com) (192.18.98.34) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Jul 2005 15:25:48 -0700 Received: from fe2.sun.com ([192.18.108.79]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6KMPpvU011809 for ; Wed, 20 Jul 2005 16:25:51 -0600 (MDT) Received: from conversion-daemon.fe2.sun.com by fe2.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) id <0IJY003015U4SR00@fe2.sun.com> (original mail from Craig.Russell@Sun.COM) for jdo-dev@db.apache.org; Wed, 20 Jul 2005 16:25:51 -0600 (MDT) Received: from [129.146.30.173] by fe2.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IJY00EI36B3HH00@fe2.sun.com> for jdo-dev@db.apache.org; Wed, 20 Jul 2005 16:25:51 -0600 (MDT) Date: Wed, 20 Jul 2005 15:25:53 -0700 From: Craig Russell Subject: Re: Binding a char to PreparedStatement In-reply-to: <200507201824.18732.andy@ajsoft.net> To: jdo-dev@db.apache.org Message-id: <4B746E79-47D1-49A7-BB31-2C5E335A4DD3@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.733) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-150--290249797; micalg=sha1 References: <42DBD7F6.50807@spree.de> <200507201757.27450.andy@jpox.org> <366DD4FB-31A5-4219-8CCF-EA871988102E@Sun.COM> <200507201824.18732.andy@ajsoft.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-150--290249797 Content-Type: multipart/alternative; boundary=Apple-Mail-149--290251296 --Apple-Mail-149--290251296 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Andy, On Jul 20, 2005, at 10:24 AM, Andy Jefferson wrote: > Hi Craig, > > >>> I'm also talking about the jdbc-type (or to be specific >>> javax.sql.Types). So >>> the JDO impl should always take JDBC Types.DOUBLE when the user has >>> a Java >>> double field? Many JDBC drivers *don't* provide a type mapping for >>> Types.DOUBLE (many don't provide support for several of the >>> "standard" JDBC >>> types). >>> >> >> I'm trying to see where the confusion is. The attribute is only >> specified if the user wants to override the default for the field >> type. Is this what you're talking about? >> > > Just trying to understand what you're proposing with respect to how > JDO impls > decide a "default" RDBMS type. You previously said that your intent > of the > spec was that the jdbc-type (when not specified) should be the > "obvious one > for the java type". I was simply pointing out that if the user has > a Java > double, then the obvious jdbc-type would be "DOUBLE", and that many > RDBMS > dont map that in their JDBC drivers, so what use is that default ? I was thinking that most of the value in the jdbc-type would be in the java-to-database schema creation, where the user could rely on the jdo impl to create appropriate schema. In the case of char or Character, that would be CHAR(1). In the case of double or Double, with a length of 20 and a scale of 12, that would be DOUBLE if the database supported it, or DECIMAL(20, 12) if not. But regardless of what was used for schema creation, I expected that when binding values to a prepared statement, the jdo impl would use the setDouble method, and when retrieving values from a result set, it would use getDouble. Similarly, unless the user had explicitly said to use jdbc-type INTEGER, I'd expect the jdo impl to use setString and getString for char fields. I had not expected that the jdbc-type would be used for deciding how to perform parameter or result set bindings. But I can see how you could implement JPOX using the jdbc-type as a clue. > > The origin of the problem Michael reported is down to the lack of a > jdbc-type > specification in the metadata, and the fact that JPOX's current > "default" for > char is to store it as INTEGER (for whatever reason) - hence why he > got the > problem. Ok. I thought that you would agree that this is a bug in JPOX, since the "obvious default" for a char column is CHAR. > > We know JPOX's internal type mapping needs more flexibility, but > the JDO spec > doesn't define what we have to do currently, so our assumption til > now was > that the user can define their required type if they have one in mind, > otherwise they take what we give them. It wasn't clear to me that the issue was flexibility, just changing the way you bind to result set and prepared statements for char types. Craig > > > > -- > Andy > 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-149--290251296 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Andy,

On = Jul 20, 2005, at 10:24 AM, Andy Jefferson wrote:

Hi Craig,


I'm also talking about the = jdbc-type (or to be specific
the JDO impl should always = take JDBC Types.DOUBLE when the user has
a = Java
double field? Many JDBC drivers = *don't* provide a type mapping for
Types.DOUBLE = (many don't provide support for several of the
"standard" JDBC
types).
=

I'm trying to see where the confusion is. The = attribute is only
specified if the user wants to = override the default for the field
type. Is this = what you're talking about?


Just = trying to understand what you're proposing with respect to how JDO = impls=A0
decide a "default" RDBMS type. You previously said = that your intent of the=A0
spec was = that the jdbc-type (when not specified) should be the "obvious one=A0
for the = java type". I was simply pointing out that if the user has a Java=A0
double, = then the obvious jdbc-type would be "DOUBLE", and that many RDBMS=A0
dont map = that in their JDBC drivers, so what use is that default = ?

I = was thinking that most of the value in the jdbc-type would be in the = java-to-database schema creation, where the user could rely on the jdo = impl to create appropriate schema. In the case of char or Character, = that would be CHAR(1). In the case of double or Double, with a length of = 20 and a scale of 12, that would be DOUBLE if the database supported it, = or DECIMAL(20, 12) if not.

But regardless of what was = used for schema creation, I expected that when binding values to a = prepared statement, the jdo impl would use the setDouble method, and = when retrieving values from a result set, it would use getDouble. = Similarly, unless the user had explicitly said to use jdbc-type INTEGER, = I'd expect the jdo impl to use setString and getString for char = fields.=A0

I = had not expected that the jdbc-type would be used for deciding how to = perform parameter or result set bindings. But I can see how you could = implement JPOX using the jdbc-type as a clue.

The origin of the problem Michael reported is down = to the lack of a jdbc-type=A0
=A0
char is to store it as INTEGER (for whatever reason) = - hence why he got the=A0
Ok. I thought that you would = agree that this is a bug in JPOX, since the "obvious default" for a char = column is CHAR.

We know = JPOX's internal type mapping needs more flexibility, but the JDO = spec=A0
doesn't define what we have to do currently, so our = assumption til now was=A0
that the = user can define their required type if they have one in mind,=A0
It wasn't clear to me that the = issue was flexibility, just changing the way you bind to result set and = prepared statements for char types.

Craig



--=A0

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-149--290251296-- --Apple-Mail-150--290249797 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHjCCAtcw ggJAoAMCAQICAw3FWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTEwMDA0MTA5WhcNMDYwMTEwMDA0MTA5WjBHMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSQwIgYJKoZIhvcNAQkBFhVDcmFpZy5SdXNzZWxsQFN1 bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDti7ZE4rO6oXKbLM02AG9WY55t udmBVL53fb3V3X5S1kvcJOk1NEMIYT/T7Ww+/hE955zvHT29+mIoNe8AW/yj1WUH8uGG2HxhwCHI UQTHmN/ioVJgjwUaYbtNMKbL/NRpnL0QWewdMJS+6IFzFyX7ADFW5cJ+UWNLvNeWAQtN0mtLildn vdOgh50i8YPvACNkCHoomGjXx0azcXbe1X3c5AgRI6e2CZe5k2lRFQFUMqkjdoMtQPoNqJ1BxH9l i4cnabl8mcTwHHl44hrvb8ThqwRf2pfJh2vVuwmgK6z4IWjOk4RQM+0ODsRdq67mBdimJYmPMK1p RMBHzrUsfKxNAgMBAAGjMjAwMCAGA1UdEQQZMBeBFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIj86LzxCHedStDLMEeqHLy+UFG7zIRHfChSIV42 +MvXicydXEBh8v0Ry1V2d/lY4jS78G5yW5R9fKt1U5nlRBCOVzdhomvSolnNRIT71wPVVDrAIVlA YpXKxSmVBq7+4hV+3ZLHDeq3qZnNmiJR0sTEUD16xZX1RJs9dRYPCHoRMIIDPzCCAqigAwIBAgIB DTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t MB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbL rzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0 cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0B AQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1 TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNzIwMjIyNTUzWjAjBgkqhkiG9w0BCQQxFgQU btiw+RCX3vmUBh8ua7wUBpgI9v0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw3FWTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwDQYJKoZIhvcNAQEBBQAEggEA wiVQeWcfeOO1ZfcsxLuw40B9GKawbEPeuzL6kKp2VhSzCqjYYRxBS+vJAosyFUqxCw9tYAuK43q5 VmnnoFnQQpwd9yAlf7CYdf9CgSNizg3E0UCeArB/yKWnB74nyJU3hKAuS3DYbTR0gx3uTes8M5xN vjzYfKN4WMrt9Vd3fYTrJR38uU5YAPnIW67GlJvECmIpxq4Y5Q8crK135MGs7dwD3YFXlnDG0we9 wpnNg82yi6HPgrFZlK4B3hlWYsFTkgaczq82XkTnB1cTtbA56XR451rtN6g2R9yO7TupmJiKbQzU +JXnWSo1AcXL7D8MTzoBNKnmYocNAFhDXwf1dgAAAAAAAA== --Apple-Mail-150--290249797--