jdaugherty commented on PR #16344: URL: https://github.com/apache/grails-core/pull/16344#issuecomment-5717241842
@matrei thanks, finding 1 is fixed in `2842f51fe0`, and I took finding 2 as well. **Finding 1.** `lockRow` now checks the entity descriptor: when the hierarchy is union-mapped (`UnionSubclassEntityPersister`) the scalar lock query targets the instance's concrete entity, otherwise the hierarchy root as before. The javadoc records the remaining limit you described: an instance whose own class has union subclasses is still rendered as a union, which is the same limit `lock()` has, and the Hibernate 7 guide gains one note next to the lock-mode table saying so. **Finding 2.** For `PESSIMISTIC_READ` and `PESSIMISTIC_WRITE` the lock mode is now recorded on the entity entry directly instead of through `session.lock`, so the instance form is two statements on Hibernate 7: the lock query and the reload. `PESSIMISTIC_FORCE_INCREMENT` still goes through `session.lock`, since that is what performs the increment. A new data-driven feature asserts the statement count for all three modes via `Statistics.prepareStatementCount`. **Tests.** Both specs gain a `tablePerConcreteClass true` root/subclass pair and the competing-commit feature pointed at the concrete table, in the same four shapes as the joined-table one (subclass load, polymorphic root load, both static forms). I also applied your `loaded.await(...) || refreshing.get(1, SECONDS)` suggestion to the joined-table features. One thing the new Hibernate 7 feature surfaced, unrelated to this PR: a freshly saved table-per-concrete-class entity lands at version 1, because the first flush issues an insert followed by an update (`entityInsertCount == 1`, `entityUpdateCount == 1` from statistics; a plain entity in the same transaction stays at 0). I reproduced it on the merge base `0980623` with `table` and `increment` generators and with an abstract root, so it predates this branch. The union feature asserts its versions relative to the saved instance with a comment pointing at this. Hibernate 5 does not do this and its feature asserts 0/1/2 literally. I will open a separate issue for it. Full `grails-data-hibernate5-core:test` and `grails-data-hibernate7-core:test` runs (`cleanTest`-equivalent via `DO_NOT_CACHE_TESTS=1`, `--no-build-cache`) and `codeStyle` on both modules are clean: | Run | Result | |---|---| | `grails-data-hibernate5-core:test` (full, incl. `Hibernate5RefreshLockSpec` 77/77) | 915 tests, 0 failures, 39 skipped | | `grails-data-hibernate7-core:test` (full, incl. `Hibernate7RefreshLockSpec` 79/79) | 3158 tests, 0 failures, 29 skipped | | `codeStyle` on both modules | clean | -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
