Quarkus: Support JPA Entity Lifecycle Callbacks

[AlbozDroid]

Description
Implement JPA Callbacks

JPA defines the following Entity lifecycle callbacks:
@PrePersist - before a new entity is persisted (added to the EntityManager).
@PostPersist - after storing a new entity in the database (during commit or flush).
@PostLoad - after an entity has been retrieved from the database.
@PreUpdate - when an entity is identified as modified by the EntityManager.
@PostUpdate - after updating an entity in the database (during commit or flush).
@PreRemove - when an entity is marked for removal in the EntityManager.
@PostRemove - after deleting an entity from the database (during commit or flush).

Hibernate implements them all, however, they are not supported in Quarkus according to:

https://quarkus.io/guides/hibernate-orm#limitations.

They are useful to schedule events and actions. As an example, we use the @PostPersist and @PostUpdate callbacks to keep in sync the database and elasticsearch. The DB is the single source of truth and when something changes in the DB the record should be refresh in the search engine (Elastic).

The above is just an example, but there are many others too.

Implementation ideas

The implementations already exist in Hibernate.

[famod]

Hm, this documentation bit seems outdated. Both @PrePersist and @PreUpdate are working as expected in my/our Quarkus app.

/cc @Sanne @gsmet

[Sanne]

@famod I'm pretty sure they won't work in native, and users will also be likely to expect CDI integrations to work.

[famod]

@Sanne I see. Maybe we should refine the docs?
I and my team are not the only ones using those callbacks already (see other issues).

[Sanne]

Sure we could refine the docs, but it bothers me to have some funtionality which only works in JVM mode; I'd much rather keep it simple and document this is not supported yet - if it works for you you're "trespassing" the intent :)

It would set a bad precedent for other extension developers to have some features that behave differently in native-images - everything becomes more complex if each sub-feature needs a flag "works in native", we strived from the beginning to send a clear message: Quarkus apps which work in JVM will work the same in native.

This principle becomes important when you find yourself in need of a native debugger: most Java developers would rather not need to see one ever, so it's rather important that an application is semantically consistent between its JVM mode and its native mode - it really helps to keep the differences to a minimal, so that most issues can be debugged in JVM mode, then compiled to native later.

Maybe to be coherent with this principle I should make sure people don't use callbacks in JVM mode either :) But I'm trying to be pragmatic here, and I guess we should rather spend our time to fix this limitation in native. To be fair I wanted this done months ago, I have to apologize we've been a bit overwhelmed by our own success - I'll see what we can do.

[AlbozDroid]

Personally, I think Quarkus should strive to have full support for Microprofile specs and Hibernate (fully JPA compliant). They're the backbone of Java Web Apps and the only serious alternative to Spring/SpringBoot.

[Sanne]

@AlbozDroid agreed, and no worries we'll implement these JPA callbacks. It's a limitation we inherited from the very initial POC, we simply never had the time but it's not inherently too difficult :)

To me it was also interesting that nobody had opened this issue yet ;-) It's a strategy to prioritieze things.

[famod]

@Sanne

I totally get the "it shall work in native" goal.

Maybe to be coherent with this principle I should make sure people don't use callbacks in JVM mode either

Please don't! If you do I am sure you will see more issues than you want. 😉

To me it was also interesting that nobody had opened this issue yet

There is another one, more or less: #6948

we've been a bit overwhelmed by our own success

Not the worst thing to happen I would say. 😁

[Sanne]

thanks @famod ! Sure no worries I'm not disabling it yet, we are otherwise busy :)

[stuartwdouglas]

What is the issue with native here? Just a matter of registering them for reflection?

[Sanne]

@stuartwdouglas probably yes, I haven't looked at it in a while. AFAIR the whole handling of JPA callbacks needs a general refactoring: it entirely relies on runtime annotation processing, reflective bean instantiation, etc.. and there's probably some ArC integration to do as well.

"Just" adding a list of stuff to reflection could do the trick, but it also implies we need to keep a significant chunk of metadata held in memory so I would hope someone could dedicate some days to explore the better solution.