@Nationalized probably not working with Hibernate Envers audit

Hibernate ORM
1

I am using Spring Boot with Hibernate Envers to manage audit tables in a SQL Server database.

To optimize performance and handle non-Unicode strings properly, I updated my SQL Server connection string as follows:

spring.datasource.url=jdbc:sqlserver://localhost:1433;databaseName=mydb;sendStringParametersAsUnicode=false

2

Soo, what’s the problem? I don’t understand why you’re even posting this..

3

I fixed it, but the problem is very clear: nationalized doesn’t work for enverse, and the audit table does save.?? in column

4

I don’t understand what you expect. The documentation for the sendStringParametersAsUnicode connection string property clearly states that it will send data in ASCII format, so if you send non-ASCII characters, you’re simply gonna send rubbish to the server.

5

I think you do not have experience in international companies. For example, first names, last names, or addresses of any region need to be saved in the database using their local language, and they usually should not be in ASCII. and it’s very important data”

@Nationalized worked in Hibernate, but doesnt work in Envers to send NVARCHAR to db in this mode

6

So let’s break down what seems to be happening

  • The JVM stores your character data in a Unicode encoding as String.
  • You set a field annotated as @Nationalized to a value containing non-ASCII characters
  • Hibernate ORM sends that data to the JDBC driver by calling PreparedStatement#setNString
  • The driver sends rubbish to the server, probably because you configured this setting

Now, how did you come to the conclusion that it is Hibernate ORM is at fault here?

Unless you can provide actual evidence that Hibernate ORM does something wrong, you can try and ask if the Microsoft SQL Server JDBC driver team can help you with the little information you provided here so far.

Maybe there is a bug somewhere in Hibernate ORM, but with the information you shared here so far, nobody would be able to help you. Try asking a colleague who has no idea about the actual issue you’re facing if the topic you created here has enough information for someone, who isn’t you, to understand what the problem is.

7

I’m sorry I shared my problem with you; it’s quite clear, but I think you may not fully recognize the issue. It’s actually pretty straightforward.

To improve performance when using an SQL database, you should set sendStringParametersAsUnicode=false to ensure that strings are sent to the database by default with JDBC. This allows properly handling of nationalized characters (send NString)in the columns. However, I’ve noticed that the audit tables do not work with nationalized characters and instead show “??” in the audit table.

Before proceeding to judge, please research this topic online or set up this environment on your local machine.

This issue is common on the internet.

But I solved it. I can help you if you’re facing SQL issues with this configuration.

8

After looking a bit deeper into this matter, I realized that there is in fact a bug and created HHH-19976 to track this.
Thanks for reporting it, but next time you report something, please try to create a reproducer with our test case template and or at least gather some details about what you think might be wrong.
As you can imagine, we get a lot of questions/requests which are simply the wrongdoing of users and it’s not easy for us maintainers to delve into every user scenario.

9

I still believe that the first question is clear if you examine the audit table in different scenarios. This is my solution until support for the audit table includes a version of Hibernate for the audit entities using the @Nationalized annotation:

Thanks for fixing this in the future

10

@beikov Can you assign this task to me? I’d like to do that.

11

As you can see on the ticket, I already started working on it and have a fix: HHH-19976 Don't adopt AdjustableBasicType name to create derived type by beikov · Pull Request #11384 · hibernate/hibernate-orm · GitHub

12

Oh, that’s great. I really wanted to fix this bug myself.