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