`@NotNull` does not add `not null` to persistence unit

[LarsSven]

Describe the bug

With Hibernate ORM, we have an entity that has a @NotNull annotation. According to documentation, Hibernate should pick this up and add not null to the column in the Persistent Unit. However, when you do that on Quarkus 3.18.1, not null is not added to the persistence unit.

This used to be properly applied, until at some point we discovered after a few Quarkus updates that this suddenly no longer happens, so I am not sure in which version this stopped working.

I made a small reproducer at https://gitlab.com/l.s.andringa1/quarkus-hibernate-non-null-reproducer

The project is in Kotlin since that is what we are used to. I am not sure whether it only happens on Kotlin or also on Java. I tried to put both kotlin and java entities in the same project to test, but it was not added to the same persistence unit.

Expected behavior

When @NotNull is added to an entity, as follows:

@Entity
class MyKotlinEntity {
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Id
    var id: Long? = null

    @NotNull
    var field: String = ""
}

The persistence unit (for MariaDB in this case) should look like:

create table MyKotlinEntity (
    id bigint not null auto_increment,
    field varchar(255) not null,
    primary key (id)
) engine=InnoDB;

Actual behavior

When @NotNull is added to an entity, as follows:

@Entity
class MyKotlinEntity {
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Id
    var id: Long? = null

    @NotNull
    var field: String = ""
}

The persistence unit looks as follows:

create table MyKotlinEntity (
    id bigint not null auto_increment,
    field varchar(255),
    primary key (id)
) engine=InnoDB;

How to Reproduce?

Reproducer:

1. Clone https://gitlab.com/l.s.andringa1/quarkus-hibernate-non-null-reproducer
2. Open Quarkus dev dashboard and look at Hibernate ORM persistence unit
3. Observe the Create Script, which is missing the not null annotation for the field

Output of uname -a or ver

Windows 11 (Also tested on Ubuntu 24.10)

Output of java -version

OpenJDK Runtime Environment Corretto-21.0.5.11.1

Quarkus version or git rev

3.18.1

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 8.12.1

Additional information

No response

[quarkus-bot]

/cc @geoand (kotlin)

[yrodiere]

Hello,

Thanks for reporting, and for the reproducer.

It does seem there is a problem with @NotNull not being reflected in generated schema.

I checked that it's not related to:

• Kotlin. I tried to replace your Kotlin entity with a Java one in your reproducer and got the same behavior.
• Our support of public fields. Switching to private fields with manually defined getters/setters yields the same behavior.

For the person doing further investigation (maybe me, maybe not):

1. The code in Hibernate ORM is here: https://github.com/hibernate/hibernate-orm/blob/9a4d21d71d2620a0093543d84e8f464107e4d2f4/hibernate-core/src/main/java/org/hibernate/boot/beanvalidation/TypeSafeActivator.java#L317-L345
2. That code gets triggered by an integrator here: https://github.com/hibernate/hibernate-orm/blob/3769d4c2339c0c7ad575fc156d56bd8d87b9ef30/hibernate-core/src/main/java/org/hibernate/boot/beanvalidation/BeanValidationIntegrator.java#L88

It's just a guess, but I suspect that, in Quarkus, that integrator gets triggered too late. Dev UI code relies on Metadata only, in particular, so it may generate scripts before integrators get... integrated.

[LarsSven]

@yrodiere does that mean that even though the not null may not properly be reflected in the dev UI (which is of course still a problem, especially since we use it to populate flyway), Hibernate still adds not null to it in the actual database scheme?

Also for the env/windows, I also tested it on Ubuntu and had similar issues there.

[yrodiere]

@yrodiere does that mean that even though the not null may not properly be reflected in the dev UI (which is of course still a problem, especially since we use it to populate flyway), Hibernate still adds not null to it in the actual database scheme?

I didn't check. That's possible. Though if I had to bet, I'd rather go for the option "it doesn't work either way, but for different reasons" 😅

Also for the env/windows, I also tested it on Ubuntu and had similar issues there.

Yep, I use Linux as well, that's why I removed env/windows. It was added by a bot because your initial report mentioned Windows.

[LarsSven]

@yrodiere what is the status of this issue? Is there still a plan to look into this issue? Since it is quite annoying for our team.

[yrodiere]

It's in the backlog, someone will look into it when they have time. Not the only issue to work on unfortunately.

If your team want to speed things up, both Quarkus and Hibernate ORM gladly welcome contributions -- just make sure to tell us you're working on this.

[marko-bekhta]

hey,
I think this behaves as expected. For validation constraints to get reflected in the generated schema the jakarta.persistence.validation.mode has to be set to DDL (https://docs.jboss.org/hibernate/orm/6.6/javadocs/org/hibernate/boot/beanvalidation/ValidationMode.html#DDL) but since in Quarkus we have the boolean flag (https://quarkus.io/guides/hibernate-orm#quarkus-hibernate-orm_quarkus-hibernate-orm-validation-enabled) to enable the Validatior integration with ORM we only allow users to pick CALLBACK or NONE values.

quarkus/extensions/hibernate-orm/deployment/src/main/java/io/quarkus/hibernate/orm/deployment/HibernateOrmProcessor.java

Lines 1106 to 1115 in 046dc99

	// Hibernate Validator integration: we force the callback mode to have bootstrap errors reported rather than validation ignored
	// if there is any issue when bootstrapping Hibernate Validator.
	if (capabilities.isPresent(Capability.HIBERNATE_VALIDATOR)) {
	if (persistenceUnitConfig.validation().enabled()) {
	descriptor.getProperties().setProperty(AvailableSettings.JAKARTA_VALIDATION_MODE,
	ValidationMode.CALLBACK.name());
	} else {
	descriptor.getProperties().setProperty(AvailableSettings.JAKARTA_VALIDATION_MODE, ValidationMode.NONE.name());
	}
	}

I'd suggest using Flyway/Liquibase for production-kind applications to manage the schema.

[yrodiere]

I'd suggest using Flyway/Liquibase for production-kind applications to manage the schema.

True, but we do allow Hibernate ORM to generate the first iteration of the schema and use it as a Flyway script, and we do allow validating the (Flyway-managed) schema with Hibernate ORM, both of which are reasonable and would be affected by this behavior.

I think this behaves as expected

Given your explanation, it makes sense... but the report mentions this is a regression compared to previous versions... ? Something changed in this area, didn't it? Was DDL the default previously, and we changed it to CALLBACK by accident? Should we consider allowing to pick DDL explicitly, or using it by default?

[gsmet]

I think it was always set to callback. Do we have an option that both provides the DDL and allow HV integration?