HIBERNATE ORM WITH PANACHE

[Venki028]

I've recently started using Quarkus with Hibernate ORM Panache for saving entities. The persist method works fine for saving, but I'm encountering an error saying "detached entity" when trying to update an entity using persist. I'm using the repository pattern and annotating the repository class with @Transactional, but not the service class.

After some research, I found that I don't need to use persist for updating; the entity will get updated automatically if it is modified. However, I don't understand this design choice. Most of the time, I fetch entities without the intention of updating them, so I don't see why they should be updated automatically.

Could you explain the rationale behind this design and possibly share the proper architecture or approach for handling such scenarios? This would be very helpful.

@StFS #Panache

[quarkus-bot[bot]]

/cc @FroMage (panache), @gsmet (hibernate-orm), @loicmathieu (panache), @yrodiere (hibernate-orm)

[yrodiere]

I found that I don't need to use persist for updating; the entity will get updated automatically if it is modified.

You actually must not call persist for updating. persist is strictly about creating.

"persistent" entities are indeed updated automatically on transaction commit (technically on flush, but the distinction doesn't matter here).

If you're serializing your entities instead of using proper DTO ( 🫤 ), that means your entity must be made "persistent" (attached to the session) when you want to update it.

However, I don't understand this design choice. Most of the time, I fetch entities without the intention of updating them, so I don't see why they should be updated automatically.

Others will say that they would hate to see their calls to entity setters ignored, if they make such calls. Because ignoring such calls is a recipe for bugs.

Really, opinions differ a lot in that area.

Could you explain the rationale behind this design

I can't. JPA spec contributors could.

and possibly share the proper architecture or approach for handling such scenarios?

I don't have the time to go through the basics of JPA right now, unfortunately. Perhaps someone else does, but if not, you can have a look at this introduction which should cover what you need: https://docs.jboss.org/hibernate/orm/6.5/introduction/html_single/Hibernate_Introduction.html#interacting

If you don't care about JPA's features (and complexity), and want something closer to the database, StatelessSession would be one way to do what you want... but it's not supported in Panache. Yet.

[Venki028]

@yrodiere Thanks for your explanation.
/cc @FroMage (panache), @gsmet (hibernate-orm), @loicmathieu (panache), @yrodiere (hibernate-orm)

I'm currently working on two projects. One uses Quarkus 3.7.4 and the other uses Quarkus 3.11.1.. In the first project (using Quarkus 3.7.4), when I try to find an entity, it fetches from the database and runs an update on the entity, even though I haven't modified any fields. However, I am not encountering this issue in the second project (using Quarkus 3.11.1). Could you help me understand why this discrepancy occurs and how to resolve the issue in Quarkus 3.7.4?
Note : The problem is that I am just fetching the values from entity without updating it but still the update query is triggered
We Followed a similar repository pattern for both applications with Hibernate Panache ORM

[yrodiere]

Note : The problem is that I am just fetching the values from entity without updating it but still the update query is triggered

That's possibly just a result of dirty tracking not working correctly. I've seen such problems happen on custom user types, or JSON columns in some cases.

In particular, we've had bugs like this in the past, so it's possible you are just hitting such a bug.

Could you help me understand why this discrepancy occurs and how to resolve the issue in Quarkus 3.7.4?

I'm afraid if that problem only happens on unmaintained versions of Quarkus, we've reached the limit of what I can afford to do to help. I'd suggest you just upgrade.

Now if you can reproduce this on Quarkus 3.8 or 3.11, that's another problem entirely, and you can create a bug report so someone will have a look.