Hi Pramod,
It sounds like backing out the changes may be the best choice.
As for the precision default of '0', if we make this fix, we will have
to do it in code that is isolated to the EJB 3.0 implementation, so that
it will remain backward compatible for customers that exclusively use
Core TopLink.
-Tom
Pramod Gopinath wrote:
>Hi Tom
> Based on a re-read of the spec, we think that we can back out the
>changes that I had suggested for FLOAT and DOUBLE in OraclePlatform. In
>the case where the user wants to enter in FLOAT.MAX_VALUE and/or
>DOUBLE.MAX_VALUE for Oracle they would have to use the ColumnDefinition
>part of the @Column annotation and use "NUMBER" or "NUMBER(*,??)".
>Would also have to state this in the documentation so that users are
>aware of this.
>
>This is based on section 9.1.5 which states that for precision default
>is "0 (Value must be set by developer)". In this case for decimal
>fields the users should always be specifying the precision and scale.
>This leads to another issue. The current implementation is not spec
>compliant. If a value of 0 is found, we then create fields based on the
>definitions in the corresponding platform. This is wrong. Yes, this is
>not a user friendly approach but that is what we understand of the spec
>at this point. This issue has not been addressed in the final version
>too of the spec.
>
>Thanks
>Pramod
>
>
>Tom Ware wrote:
>
>
>>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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com