[
https://hibernate.onjira.com/browse/HHH-7060?page=com.atlassian.jira.plug...
]
John Verhaeg updated HHH-7060:
------------------------------
Description: In particular, there is a disconnect between the value ranges supported
by bytes in Java vs. SQL Server: Java byte values are 1 byte, unsigned, while SQL Server
values are 0-255. Previously, negative byte values stored in the Java model would be
treated as unsigned bytes by the driver, allowing the reading and writing of such values
to "work" from the standpoint of the application, but also resulting in a
completely different positive value being stored within the database. HHH-6815 addressed
this disconnect from the standpoint of ensuring values set in the Java model were kept
semantically in tact within the database and forcing the use of SMALLINT columns instead
of TINYINT columns for byte values. However, this solution assumes it's important
that the database values exactly match what's in the Java model. It also does not
allow for existing databases with existing TINYINT columns, which end up experiencing
exceptions when negative byte values are persisted and later retrieved. The proposed
solution is to offer some type of mode that can be set by the user to indicate the Java
model should be treated as authoritative wrt data values, which would cause Hibernate to
perform as it did in previous releases. (was: In particular, there is a disconnect
between the value ranges supported by bytes in Java vs. SQL Server: Java byte values are 1
byte, unsigned, while SQL Server values are 0-255. Previously, negative byte values
stored in the Java model would be treated as unsigned bytes by the driver, allowing the
reading and writing of such values to "work" from the standpoint of the
application, but also resulting in a completely different positive value being stored
within the database. HHH-6815 addressed this disconnect from the standpoint of ensuring
values set in the Java model were kept semantically in tact within the database and
forcing the use of SMALL_INT columns instead of TINY_INT columns for byte values.
However, this solution assumes it's important that the database values exactly match
what's in the Java model. It also does not allow for existing databases with existing
TINY_INT columns, which end up experiencing exceptions when negative byte values are
persisted and later retrieved. The proposed solution is to offer some type of mode that
can be set by the user to indicate the Java model should be treated as authoritative wrt
data values, which would cause Hibernate to perform as it did in previous releases.)
Add support for mode that causes SQL Server dialect to treat
application as semantically authoritative in regards to Java types and their value ranges
------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-7060
URL:
https://hibernate.onjira.com/browse/HHH-7060
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.0
Reporter: John Verhaeg
Assignee: John Verhaeg
In particular, there is a disconnect between the value ranges supported by bytes in Java
vs. SQL Server: Java byte values are 1 byte, unsigned, while SQL Server values are 0-255.
Previously, negative byte values stored in the Java model would be treated as unsigned
bytes by the driver, allowing the reading and writing of such values to "work"
from the standpoint of the application, but also resulting in a completely different
positive value being stored within the database. HHH-6815 addressed this disconnect from
the standpoint of ensuring values set in the Java model were kept semantically in tact
within the database and forcing the use of SMALLINT columns instead of TINYINT columns for
byte values. However, this solution assumes it's important that the database values
exactly match what's in the Java model. It also does not allow for existing databases
with existing TINYINT columns, which end up experiencing exceptions when negative byte
values are persisted and later retrieved. The proposed solution is to offer some type of
mode that can be set by the user to indicate the Java model should be treated as
authoritative wrt data values, which would cause Hibernate to perform as it did in
previous releases.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira