A good example is our internal testing. (And potentially a customer's
testing).
Our testing uses table generation to build tables we use in population.
Changing the default value of the NUMBER's precision, causes the values
stored in at table generation time to be different from the java values
in the objects and therefore means we cannot do a comparison between
what is in the DB and what is in Java.
I am in favour of allowing as many as possible Double or Float values to
be stored by default. But anything that breaks our regression tests is
a potential issue for customers. Additionally, although I am not
opposed to the solution that uses '*', I am not sure if the amount of
testing it would require is practical at this time. Beyond that, I am
not sure if we are really making the product much weaker by not allowing
some really high values in the default case, particularly when it is
possible to allow them with simple overrides and when users will likely
only use this feature for quick development and will create their own
tables for production versions.
-Tom
Marina Vatkina wrote:
>Tom, Peter,
>
>What's wrong with using NUMBER without any specific precision and scale?
>How does it break backward compatibility? If a user already has tables
>generated with NUMBER(19, 4), nobody is replacing those tables. And if
>they regenerate the tables with the new code (i.e. they loose all the data
>anyway), what would be wrong if the new column definition allows to store
>any float or double value?
>
>thanks,
>-marina
>
>Tom Ware wrote:
>
>
>>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>