My thoughts exactly.
My concern is what (*, scale) does on older versions of the Oracle DB (pre 9.2).
I question exactly what the purpose of this change is. I wonder if it is not the testcase that should change? The provider picking a logical default for Oracle of say 32 should be fine. If the user requires more room, they should specify it. Changing the field type to be string for one case seems over kill to me.
-----Original Message-----
From: Tom Ware [mailto:tom.ware_at_oracle.com]
Sent: Thursday, February 16, 2006 9:37 AM
To: persistence_at_glassfish.dev.java.net; Peter Krogh;
Geoffrey.Halliwell_at_Sun.COM
Subject: Re: REquest for review of code changes
Hi Pramod,
In principal, I like the idea of using NUMBER(*, scale).
There needs to be some dicussion about the amount of testing we should
do in order to make this change. We will have to ensure this works on a
wide range of Oracle databases. In addition, since there will be a
change to some of the base classes for schema generation, we will also
have to run tests on a number of the other supported databases to ensure
no regression in functionality.
Peter will also likely want to weigh in on this.
-Tom
Pramod Gopinath wrote:
>Hi Tom
> This is some information that I have found based on digging around in
>the Oracle documentation for NUMBER datatype.
>
>I am referring to the document "Oracle 9i Database Concepts Release 2
>(9.2) Part Number A96524-01".
>I accessed it by signing into OTN. The Url was
>http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/toc.htm
>
>Based on what I saw in this document, we could potentially create a
>number field as NUMBER(*, scale) where scale can range from -84 to 127.
>By leaving the precision part as "*", it is guaranteed that the field
>would support up to 38 digits precision. So if I define a field that is
>NUMBER(*, 4) and try to insert ava.lang.Float.MAX_VALUE (3.4028235E38)
>into this field, the insert would work. When I query the table I would
>get back a value of 3.4028E38.
>
>We cannot use NUMBER(38,4) because in this case the precision would be
>restricted to 34 digits. Hence if we try to insert
>java.lang.Float.MAX_VALUE (3.4028235E38) into this field we would get an
>error.
>
>Since the prior version of OraclePlatform had the FLOAT field defined as
>NUMBER(19,4), we could change that to be NUMBER(*,4). This would ensure
>that we would be able to support the maximum allowable size as well as
>take care of the backward compatibility iissue of having a subsize. I
>know that the immediate file affected to make this change would be
>FieldTypeDefinition but am not sure about the complete impact of this
>proposed change.
>
>Wanted to get your input before I dig deeper into the code changes
>required to do this change.
>
>Thanks
>Pramod
>
>
>Tom Ware wrote:
>
>
>>Hi Pramod,
>>
>> I have run some testing on the change to OraclePlatfrom and there is
>>an issue that needs to be resolved.
>>
>> The change eliminates an important default which breaks backward
>>compatibility of TopLink for users using core TopLink table creation.
>>(rather than the GlassFish java2db). We rely on the existence of a
>>default subsize when we create tables. We need to find a solution
>>that allows us to still maintain a default for this value.
>>
>>-Tom
>>
>>
>>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com