Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Default UUID type incorrectly maps to SQL Server's uniqueidentifier

Description

SQL Server uses a specific byte order when mapping Java UUID values to SQL Server uniqueidentifier values. See https://github.com/microsoft/mssql-jdbc/blob/62ac085563aa263415b5ac0db5cf178ba19d2d63/src/main/java/com/microsoft/sqlserver/jdbc/Util.java#L669-L701 for details.

The current behavior of Hibernate is to use the standard byte order to convert a UUID to byte[]. As a result UUID values can be written to the database and can be read again. But when writing an ad-hoc SQL query with a literal UUID value in it (SQL Server will transparently convert a string to a uniqueidentifier), the query will not find the desired rows if the UUID value was obtained from the Java code (e.g. logs or some server response).

As a workaround the @Type("uuid-char") annotation can be used, but that of course has some performance and I/O overhead.

duplicates

Activity

Show:

Christian Beikov September 13, 2022 at 8:49 AM

This is not a bug, but a feature request. We simply don't support all types which are not covered by JDBC. I created https://hibernate.atlassian.net/browse/HHH-15504#icft=HHH-15504 for adding the type mapping. In the meantime, you can create a custom UserType that binds values in the correct byte order.

Duplicate

Details

Assignee

Reporter

Components

Affects versions

Priority

Created May 31, 2022 at 1:35 PM
Updated September 13, 2022 at 8:49 AM
Resolved September 13, 2022 at 8:49 AM