Ankur Mhatre
7b06d653e4
Adds a JUnit test suite (GetVsGetReferenceTest, MergeRefreshTest, OptimisticLockTest, IdentityBatchTest, SequenceBatchTest, AllocationSizeSweepTest, BatchSizeSweepTest) so every surprising behavior described in the three companion posts has a reproducible test, alongside the original CommandLineRunner scenarios. Rewrites all three doc chapters and the README around the new experiments: the get()/getReference() same-session matrix, the merge()/refresh() experiments (including exactly when OptimisticLockException surfaces and a corrected LAZY-plus- cascade merge() result), and two new sweeps (allocationSize, batch_size) for batch inserts.
46 lines
2.5 KiB
Markdown
46 lines
2.5 KiB
Markdown
# 00 — Versions
|
|
|
|
[Next: 01 — get() vs load() →](01-get-vs-load.md)
|
|
|
|
This repository is pinned to:
|
|
|
|
| Component | Version | GA date | Source |
|
|
|---|---|---|---|
|
|
| Hibernate ORM | `7.4.1.Final` | 2026-06-09 | [hibernate.org/orm/releases/7.4](https://hibernate.org/orm/releases/7.4/) |
|
|
| Spring Boot | `4.1.0` | 2026-06-10 | [spring.io/blog/2026/06/10/spring-boot-4](https://spring.io/blog/2026/06/10/spring-boot-4/) |
|
|
| Java | `25` (LTS) | 2025-09 | latest LTS at the time this repo was built |
|
|
| H2 | managed by Spring Boot 4.1.0 | — | in-memory, `DB_CLOSE_DELAY=-1` |
|
|
|
|
## The pin lines up, but check before you assume it always will
|
|
|
|
`hibernate-core`'s own `maven-metadata.xml` on Maven Central lists `7.4.6.Final` as the newest
|
|
GA release at the time this was written — several patches ahead of `7.4.1.Final`. This repo
|
|
pins to `7.4.1.Final` deliberately, because that is the version this batch of posts was written
|
|
and run against, and because it is *exactly* the version Spring Boot 4.1.0 resolves on its own.
|
|
|
|
That last part is not a coincidence to take for granted, though. Checking
|
|
`spring-boot-dependencies-4.1.0.pom` directly shows `<hibernate.version>7.4.1.Final</hibernate.version>` —
|
|
so on Boot 4.1.0, `pom.xml` in this repo does not need to override anything to get 7.4.1.Final;
|
|
the `<hibernate.version>` property declared here is redundant with what Boot already resolves,
|
|
kept only so the pin is visible without cracking open Boot's own POM.
|
|
|
|
That stops being true one patch release later. `spring-boot-dependencies-4.1.1.pom` resolves
|
|
`hibernate.version` to `7.4.5.Final` — a different Hibernate patch from the same Spring Boot
|
|
minor version, four Hibernate patch releases apart. If you bump this repo's parent to `4.1.1`
|
|
without touching the `<hibernate.version>` property, you get `7.4.1.Final` back (the explicit
|
|
property now *does* override Boot's own management) rather than the `7.4.5.Final` Boot intended
|
|
you to get — which is a more useful trap to know about than to fall into.
|
|
|
|
| Spring Boot version | Hibernate version Boot resolves |
|
|
|---|---|
|
|
| `4.0.8` | `7.2.24.Final` |
|
|
| `4.1.0` | `7.4.1.Final` |
|
|
| `4.1.1` | `7.4.5.Final` |
|
|
|
|
Verified against `maven-metadata.xml` on `repo1.maven.org`, not against Maven Central's
|
|
`solrsearch` API — that index has been observed stale from this kind of sandboxed build
|
|
environment (it reported an old Spring Boot release as newest well after a later one had
|
|
shipped), so it should not be trusted for currency checks.
|
|
|
|
[Next: 01 — get() vs load() →](01-get-vs-load.md)
|