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
>