|
|
|
|
|
Change By:
|
Gail Badner
|
|
Summary:
|
Column generated for big_integer properties BigIntegerType should have scale=0 by default use BigIntTypeDescriptor
|
|
Issue Type:
|
Improvement Bug
|
|
The scale Currently, BigIntegerType specifies NumericTypeDescriptor.INSTANCE as its SqlTypeDescriptor; instead it should be 0 for the column generated for a property use org.hibernate.type.descriptor.sql,BigIntTypeDescriptor.INSTANCE.
A consequence of NumericTypeDescriptor.INSTANCE being defined is that columns involved in properties of "big_integer" type are treated as java.sql.Types. BIGINT NUMERIC . Currently, the default is 2 This means that such columns are:
* bound using PreparedStatement . setBigDecimal();
* extracted using ResultSet.getBigDecimal();
Making this change will fix problems with SQL Server sequences of * exported using the type bigint mapped by the dialect for java . By default sql.Types.NUMERIC (e.g. , a bigint sequence ranges from -9 for H2Dialect , 223 the column would be exported as decimal(19 , 372,036,854,775,808 2) by default).
By changing BigIntegerType to 9 specify org.hibernate.type.descriptor.sql , 223,372,036,854,775,807 BigIntTypeDescriptor . INSTANCE as its SqlTypeDescriptor, columns for "big_integer" properties will be
* bound using PreparedStatement.setLong();
By default, * extracted using ResultSet.getLong();
* exported using the first sequence value returned type mapped by SQL Server is -9 the dialect for java.sql.Types.BIGINT (e.g. , 223 for H2Dialect , 372,036,854,775,808. With the current column would be exported as bigint by default ).
Dialects already register a type to be used for java.sql.Types.BIGINT that has scale =0, either implicitly ( of 2) e.g , SQL Server throws H2Dialect has : com registerColumnType( Types . microsoft BIGINT, "bigint" )), or explicitly (e . sqlserver g . jdbc.SQLServerException , Oracle8iDialect has : Arithmetic overflow error converting numeric to data type numeric registerColumnType( Types . BIGINT, "number(19,0)" )). This mapping is properly used for "long" properties. When this is fixed, the same mapping will be used for "big_integer" properties.
See This issue will fix HHH-9250 for more details of the failure on SQL Server . The fix for HHH-9250 simply changes changed the mapping for a test that fails using SQL Server to explicitly set scale="0" as a workaround.
In order to restore the legacy behavior, an application will have to override the "big_integer" type with a custom type that specifies NumericTypeDescriptor.INSTANCE as its SqlTypeDescriptor.
|
|
|
|
|
|
