Triggers/autogenerated values for Partial keys in Hibernate ORM

[LarsSven]

So I essentially have an entity that looks like this in Hibernate ORM (with kotlin):

@Entity
@Immutable
@IdClass(AssignmentConfigId::class)
class AssignmentConfig(
    @Id
    @field:ManyToOne(fetch = FetchType.EAGER)
    var assignmentProfile: AssignmentProfile,

    @field:NotBlank(message = "Configuration cannot be null or blank")
    @field:Column(updatable = false, columnDefinition = "JSON")
    var config: String,
) {
    @CreationTimestamp
    lateinit var created: Instant

    @field:Id
    @field:Min(1, message = "Revision must be greater than or equal to 1")
    var revision: Int = 1
}

The primary key is a combination of the revision and the profile backreference. There is a lot of advantages for our project with doing this rather than using a UUID, so we'd really prefer to use a compound key like this.

The problem is that we want to autoincrement the revision within the same assignmentProfile. So we essentially only have to specify the assignmentProfile, and the revision gets autogenerated based on how many AssignmentConfigs there are in the database. We know identity generation is not supported for partial keys, so we have a trigger in the database that automatically generates this for us (so the database takes care of this). We are however really struggling to figure out how to make Hibernate aware that this field is getting autogenerated and then to play well with it.

Is there any way that we could either:

1. Implement the autoincrementing of the revision in Hibernate
2. Make Hibernate play well with the database itself autogenerating the revision through a Trigger?

We would really appreciate any help or pointers on this.

[quarkus-bot[bot]]

/cc @geoand (kotlin), @gsmet (hibernate-orm)

[mbellade]

Hello @LarsSven, since the column is populated by a database-side trigger, you should be able to simply annotate your revision field with Hibernate's @Generated annotation and it should make it retrieve the value automatically: partial composite identifier value generation is now supported in the current Hibernate version (see HHH-15074 and HHH-18524), so it should work out of the box.

[LarsSven]

It is not a Kotlin issue, it is also a Java issue I can confirm. Making a small reproducer is easiest to do using Quarkus (because it has flyway for the trigger). Would it be okay if I make a small reproducer for you in Java + Quarkus? @mbladel

[mbellade]

Sure, but note that to create a trigger for your test using our template is as simple as doing something like:

entityManager.createNativeQuery("create trigger my_trigger ...").executeUpdate();

If you can't manage to reproduce the bug using Hibernate only, you can also just create a Quarkus based reproducer and link it here.

[LarsSven]

@mbladel I made a small reproducer here: https://gitlab.com/l.s.andringa1/hibernate-compose-keys

It uses Quarkus with Hibernate ORM + Panache and Flyway. A trigger is deployed that automatically generates the revision field. My team can't get this to work within Hibernate ORM.

There is a unit test there that should fail with A different object with the same identifier value was already associated with the session

[mbellade]

So there's a couple of things going on here:

1. You're using @GeneratedValue, which has a totally different meaning from @Generated. The first annotation uses a specific on-execution generator that, if no explicit value is specified, defaults to GenerationType.AUTO which will in turn choose a suited automatic identifier generation strategy for your database. The @Generated annotation instead implies the value is created on the database-side and that Hibernate should retrieve it after mutating the table.
2. You're mixing on-execution generated values with non generated, that is not supported in Hibernate ORM. That is why when you were trying to use @Generated you got the error Property of on-execution generated embeddable is not generated, which is a limitation of the framework.

I'm afraid that partially on-execution generated composite identifier values are still not supported, hence why you're getting this message, so you're going to have to find another way around the problem. A possible solution, for example, would be to retrieve the revision value in a custom BeforeExecutionGenerator implementation, which would act the same as the trigger but would allow you to set the value via Hibernate.

[LarsSven]

Is there an issue to support this feature already on Hibernate or should I create an issue for it on Jira?

[mbellade]

https://hibernate.atlassian.net/browse/HHH-16167

[LarsSven]

Which of the 3 points in there does this fall under though? I originally thought it would be part of point 2, but point 2 is fixed already and it is about Hibernate executors. Wouldn't database-generated values be a 4th point of that list of unsupported features? Or does this specific issue fall under one of the other 3 points?

[mbellade]

It is about point 2, and it has not been fixed for composite identifiers, as you can read from the comments.