I think Peter's suggestion is good. If we pick a somewhat larger value
(e.g. NUMBER(32, 4)), we should cover most possible values. Users that
wish to use larger numbers can simply override the default values.
-Tom
Pramod Gopinath wrote:
> Hi Peter
> I agree with your comments.
>
> Personally I think we should just stick to having NUMBER w/o any
> precision and scale for FLOAT & DOUBLE fields. This would ensure that
> we could take care of any scale and precision values (upto 38 digits
> each) desired by the user. This is also the recommendation that I have
> seen on many of the documents that I had "googled" over the past 2
> days when researching on this issue.
>
> The whole issue about the scale being needed has come up based on
> Tom's finding that we need a scale (subsize) when creating tables, for
> backward compatibitility reasons. I am not sure of how to deal with
> this backward compatibility issue.
>
> Thanks
> Pramod
>
> Peter Krogh wrote:
>
>>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
>>
>>
>>
>>
>>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com