DB2 到 Oracle 19C 数据库迁移中 CHAR 列的问题

Question

I am working on a backend application that runs on the JBOSS EAP 7 (JEE7) application server whose database is to be migrated from DB2 to Oracle 19c. Specifically, this application uses the Java persistence framework (JPA 2.1, Hibernate 5.1.2) to access the database and I am encountering a problem that does not occur when the application is connected to the DB2 database and it does occur when the application It is connected to the oracle DB. More specifically, the problem is in SELECT statements by primary key when the primary key field is of type CHAR (9). Let me explain: To locate a record in a specific table of the Oracle DB whose primary key is a column of type CHAR (9) and the value I am trying to locate has 8 alphanumeric positions, I only retrieve the record if I enter a blank character in the ninth position. On the other hand, this circumstance does not occur when the application is connected to the DB2 database. So I am wondering if anyone else has had this problem. Also, say that this problem that I have described does not occur if I do the SELECT with an Oracle client type SQLDeveloper. Finally, I attach the mapping of the JPA entity that I am using:

@Id
@Column(name = "POLISSA_SUBM", unique = true, nullable = false, length = 9)
public String getPolissaSubm() {
    return this.polissaSubm;
}

I also add the definition of the column in question in the oracle DB.

Answer 1

This is not a problem , but expected behavior when using the CHAR data type in Oracle. The problem as mentioned is in using the CHAR datatype.

Do not be confused, that in SQL Developer is works

For this example...

create table polissa ( polissa_subm char(9));

insert into polissa values ('MY_KEY_8');

... both queries return the expected result

select * from polissa where polissa_subm = 'MY_KEY_8';

POLISSA_S
---------
MY_KEY_8 

select * from polissa where polissa_subm = 'MY_KEY_8 ';

POLISSA_S
---------
MY_KEY_8 

This is due to Blank-Padded Comparison Semantics as documented

With blank-padded semantics, if the two values have different lengths, then Oracle first adds blanks to the end of the shorter one so their lengths are equal.

but

Oracle uses blank-padded comparison semantics only when both values in the comparison are either expressions of data type CHAR, NCHAR, text literals, or values returned by the USER function.

Unfortunatelly (actually furtunatelly ) Hibernate uses bind variables and not literals , so the padding does not happen.

You may verify is even in SQL Developer, simple run

 select * from polissa where polissa_subm = :x;

and pass an 8 byte long string - you get noting, you must pass teh full padded 9 byte string.