Question about optimistic locking/documentation

The user guide states the following (highlighting added by me):

A version or timestamp property can never be null for a detached instance. Hibernate detects any instance with a null version or timestamp as transient, regardless of other unsaved-value strategies that you specify. Declaring a nullable version or timestamp property is an easy way to avoid problems with transitive reattachment in Hibernate, especially useful if you use assigned identifiers or composite keys.

Shouldn’t this read “non-nullable”?

I’ll give you my scenario:

I want to add optimistic locking to an existing application with an existing database. I added a nullable int column to my tables and an Integer field with the Version annotation to my entities. Since I didn’t update the existing rows, all version columns are NULL.

Now when loading data, I run into the problem that Hibernate detects my instances as transient, as the documentation above states.

So wouldn’t it be better to add a not-nullable int column with the default value 0 to my existing tables and an int property to my entities? Or would it have to be a not-nullable int column in the database with an Integer property in my entities, so Hibernate can properly recognize new entities?

Thank you very much in advance!

I also found a Hibernate 6 bug related to Optimistic Locking, Caching and Lazy Loading:
https://hibernate.atlassian.net/browse/HHH-16126

I think that the following part is just a bad choice of words.

Declaring a nullable version or timestamp property is an easy way to avoid problems with transitive reattachment in Hibernate, especially useful if you use assigned identifiers or composite keys.

What this means to say is, that setting the version or timestamp property of an entity instance to null is an easy way …

I don’t think that the JIRA issue is related to your question.

Thank you very much for your answer.

What this means to say is, that setting the version or timestamp property of an entity instance to null is an easy way …

Okay, that makes more sense.

Would you thus agree that having a non-nullable version column and a nullable Java type in the entity (like Integer) would be the best way to go?

I don’t think that the JIRA issue is related to your question.

Not directly, no, but I ran into it when trying to implement Optimistic Locking in our application.

Thanks in advance!

Would you thus agree that having a non-nullable version column and a nullable Java type in the entity (like Integer) would be the best way to go?

Yes