Yanming Zhou

Please hold on until Spring Data Bom 2024.0.0 released.

@schauder How about this [improvement](https://github.com/spring-projects/spring-data-jpa/pull/3402)?

> I think this somewhat convoluted process is necessary for cases where `entity` was modified, before the call to delete, and/or to make sure optimistic locking works as intended. >...

> That's the point: If we don't use the entity passed into the method we might end up doing a delete which should fail with an optimistic locking exception. `OptimisticLockingFailureException`...

> If you want to use the positive result of the `find` call as an indication that the entity in question is managed, you'd have to use `existing` as an...

So is it worthy to perform `find()` and `merge()` then `remove()` since the exception can not be avoided completely?

I find out that `merge` gets called to avoid `InvalidDataAccessApiUsageException` not `OptimisticLockingFailureException`, because there is no way to reattach a stale detached entity in JPA, see https://stackoverflow.com/a/4438358. Here is failed...

> I just want one call to check that both things are true instead of only checking greater than, it should check greater than, and less than. I guess you...

I think it should be fixed at Spock side, it shouldn't wrap `assert` if `statement.asBoolean()` doesn't returns boolean.

```groovy assert assertThat(someString).isEqualTo('some string') ``` It happens to work before assertj add `asBoolean` method, now the `ClassCastException` is helpful to find out such weird code which should be fixed.