OneToOne mapping has unique constraint when generating schema

Hibernate ORM
1

Have mapping
EntityA
@OneToOne
@JoinColumn(name=“ent_b_id”)
EntityB entB;

EntityB
@OneToOne
@JoinColumn(name=“ent_a_id”)
EntityA entA;

According to migration docs for hibernate 6.2.2

" Previous versions of Hibernate did not create a UNIQUE constraint on the database for logical[1] one-to-one associations marked as optional. That is not correct from a modeling perspective as the foreign-key should be constrained as unique. Starting in 6.2, those UNIQUE constraints are now created.

If this causes problems for an application, creation of the UNIQUE constraint can be skipped using @jakarta.persistence.ForeignKey(NO_CONSTRAINT)."

The question is where & how can I apply @ForeignKey annotation so unique constraint generation will be skipped ?
So far I tried to apply it to @JoinColumn on both sides and it gives 0 effect I still see in the logs that schema is generated with unique constraint:

    create table EntityA (
        ent_d_id bigint unique,

    create table EntityD (
        ent_a_id bigint unique,

And of course I’m not allowed to insert 2 records that violates this constraint…
Is there way to get rid of that constraint without re-mapping to OneToMany and ManyToOne ? as it seems ManyToOne doesn’t generate unique constraint…

2

The migration guide text for this seems a bit confusing, as @ForeignKey(NO_CONSTRAINT) has no effect on uniqueness. I’ll make sure this is fixed.

If you don’t have unique values, you must map it as @ManyToOne, otherwise you might run into other problems.

3

That would be fine, but when hibernate persist within the same transaction delete of the old record and creation of new one with the same value in unique constraint column , db will flag it with constraint violation. is the only way to have manual ddl correction ?

4

If you delete and re-add values, you’re likely doing something wrong. Why can’t you just update the existing data structures to let Hibernate ORM work out the necessary update statements?
The unique constraint is correct and necessary to guarantee the data integrity as well as improve performance. If you want to go without seat-belts, then you will have to change the DDL manually.
Alternatively, why don’t you simply flush the session after you’re done with deletion? I guess the constraint violation only happens because statements are not correctly ordered, i.e. the insert happens before the delete?