Implementation of optimistic lock control to imperative, and reactive reactive mongodb-panache

[diogocarleto]

This PR is intent to bring optimist lock control to mongodb-panache, similar what we have in JPA/Hibernate. It is both supported for reactive and non reactive.

To use that we just need to use the annotation @Version in a entity field, such as:

public class Person {
  public String name

  @Version
  public Long version;
}

The optimistic lock control is supported for the methods persist/persistOrUpdate/update for one single entity or many entities, we can check that in the tests in io.quarkus.it.mongodb.panache.OptimisticLockControlRepositoryIntegrationTests and io.quarkus.it.mongodb.panache.OptimisticLockControlEntityIntegrationTests.

The changes mainly resides in io.quarkus.mongodb.panache.common.runtime.MongoOperations.

Like in jpa/hibernate, every persist/update will increment the version value. If an update fail a io.quarkus.mongodb.panache.common.exception.OptimisticLockException is raised, also similar to jpa/hibernate.

Let me know what do you think and improvements we should do here.

Fixes: #15124 Replaces: https://github.com/quarkusio/quarkus/pull/27966

[diogocarleto]

Hello @cescoffier, just created this one, didn't close the another PR yet, let me know if I can close that one.

[evanchooly]

As I've said before I don't think this belongs in panache. It is not intended to be an ODM. There are multiple options for a Mongo ODM if that's what's desired.

[evanchooly]

As I've said before I don't think this belongs in panache. It is not intended to be an ODM. There are multiple options for a Mongo ODM if that's what's desired.

[diogocarleto]

As I've said before I don't think this belongs in panache. It is not intended to be an ODM. There are multiple options for a Mongo ODM if that's what's desired.

I saw your point, for sure I respect your opinion, but I totally disagree with you, and let me explain why here.

Why we still creating Java/JVM frameworks, such as Quarkus, Micronaut, PlayFramework, and so on, if we already have Spring for a long time?

Shall we tell guys are working in JakartaEE NoSQL/JakartaEE Data to stop the work about NoSQL database because we already have "multiple options"?

What you are basically telling to new developers that arrives in Quarkus is: "go ahead and pick a 'battle tested solution', what for sure is Spring when we talk about Java'.

When I landed in Quarkus and decided to use, I considered lots of things, such as performance, and the community energy, how the platform evolves, and so on, I give a try in other MongoDB solutions before starting using Panache.

Panache guides are amazing, pretty easy to integrate and use, we are using this in production for +3 years, since we started to use, we had needs such as Optimistic Lock Control, Audit, and so on, so we implemented a similar solution to what we have in this PR.

Best.

[evanchooly]

It's about focus. Quarkus, typically, hasn't built new frameworks as such and has built integrations with existing ones in a relatively new(ish) and powerful way. In the same way, we didn't build a new persistence layer for RDBMS, we simply built on top of Hibernate. IMO, Quarkus should do the same with MongoDB libraries. This team doesn't have the bandwidth to build and maintain a whole new ODM for what it is a significantly smaller market segment than our JPA users. There are existing frameworks that already work with MongoDB and Quarkus such as quarkus-morphia (note: i'm the author of both that extension and morphia itself). Having spent the better part of a decade working on Morphia, I know firsthand how much effort that can take. Asking the quarkus team to take that on is not a reasonable thing, I don't think. Quarkus has (almost) always chose integration over reinvention and that's what should happen here.

[diogocarleto]

It's about focus. Quarkus, typically, hasn't built new frameworks as such and has built integrations with existing ones in a relatively new(ish) and powerful way. In the same way, we didn't build a new persistence layer for RDBMS, we simply built on top of Hibernate. IMO, Quarkus should do the same with MongoDB libraries. This team doesn't have the bandwidth to build and maintain a whole new ODM for what it is a significantly smaller market segment than our JPA users. There are existing frameworks that already work with MongoDB and Quarkus such as quarkus-morphia (note: i'm the author of both that extension and morphia itself). Having spent the better part of a decade working on Morphia, I know firsthand how much effort that can take. Asking the quarkus team to take that on is not a reasonable thing, I don't think. Quarkus has (almost) always chose integration over reinvention and that's what should happen here.

@evanchooly so shall we update the Panache MongoDB guides, and add some disclaimer informing that there is no plans to support Optimistic Lock Control, or even deprecated the Panache MongoDB, or if the application the guys are working get serious, they will need to support out of the box (that is my case), or change all persistence layer to another framework?

I've seen Panache evolving and growing all the time, we have Panache Rest that supports MongoDB now, mongoDB panache has supports for transactions (not in reactive yet), bug fixes, and so on.

The beauty of open source projects is that the community usually maintains right? So let's let the community maintain, or just give the community the directions.

I've tried to use Morphia in the past, and at that moment, there is a missing dependency in the version 2.xx that didn't allow me to build my project, so I sent you a message in GitHub, you sent me a message when fixed the dependence, but I've never give another try, btw it is not the case, your work in Morphia is great, there are amazing things there.

[quarkus-bot[bot]]

---

:waning_crescent_moon: This workflow status is outdated as a new workflow run has been triggered.

---

Failing Jobs - Building 658c9e262dd1511fd456d57f9ab11932ef2a5085

Status	Name	Step	Failures	Logs	Raw logs
:heavy_check_mark:	JVM Tests - JDK 11
:heavy_check_mark:	JVM Tests - JDK 17
✖	JVM Tests - JDK 17 MacOS M1	Set up runner	:warning: Check →	Logs	Raw logs
:heavy_check_mark:	JVM Tests - JDK 18

[quarkus-bot[bot]]

---

:waning_crescent_moon: This workflow status is outdated as a new workflow run has been triggered.

---

Failing Jobs - Building 0ae214db4cca07ad18809accb9ef3b76887f46a6

Status	Name	Step	Failures	Logs	Raw logs
:heavy_check_mark:	JVM Tests - JDK 11
:heavy_check_mark:	JVM Tests - JDK 17
✖	JVM Tests - JDK 17 MacOS M1	Build	Failures	Logs	Raw logs
:heavy_check_mark:	JVM Tests - JDK 18

Full information is available in the Build summary check run.

Failures

:gear: JVM Tests - JDK 17 MacOS M1 #

- Failing: integration-tests/mongodb-panache 

:package: integration-tests/mongodb-panache

✖ io.quarkus.it.mongodb.panache.reactive.ReactiveMongodbPanacheResourceTest.testMoreEntityFunctionalities line 349 - More details - Source on GitHub

java.lang.AssertionError: 
1 expectation failed.
Expected status code <200> but was <500>.

✖ io.quarkus.it.mongodb.panache.reactive.ReactiveMongodbPanacheResourceTest.testMoreRepositoryFunctionalities line 354 - More details - Source on GitHub

java.lang.AssertionError: 
1 expectation failed.
Expected status code <200> but was <500>.

[vsevel]

teams have reported that this was a wanted feature as well.

[GeniusDP]

any update here? I really need this feature

[phanngl]

I hope this will be added to Panache soon, our team also need this feature