Add this as a helper for when using alsoIf(BooleanPredicate) seems overkill
and there isn't a built in IfPresent option for the desired expression and
wanting to keep the fluid style.
The default was bumped to 300. Seeing ORA-01000: maximum open cursors exceeded
in the Oracle integration test so thinking it is due to the increase in
default preparedStatement cache.
The default was bumped to 300. Seeing ORA-01000: maximum open cursors exceeded
in the Oracle integration test so thinking it is due to the increase in
default preparedStatement cache.
Default prepared statement cache increased from 100 to 300. This could have the
effect of increased memory consumption for applications traded off with potentially
improved performance due to me cached prepared statements for larger applications.
Note that the Postgres itself has a default of 250.
* Lazy load in pre-delete does not work
* Re-add deleted beans before lazy-load will happen
* Put the contextClear() calls into a finally
This should mean that any beans put into the context would be
cleared even if there was an issue with the loadBean() call.
---------
Co-authored-by: Roland Praml <roland.praml@foconis.de>
* creates support for generics in mapped superclasses
* Changes DeployCreateProperties to allow processing of inheritance hierarchies with generics
* adds tests for ebean-querybean
* bumps querybean-generator version
* fixes tests by changing table names for ProductWithGenericLong and ProductWithGenericString
* Restore format, this reduces the diff
* Restore format, this reduces the diff
---------
Co-authored-by: Rob Bygrave <robin.bygrave@gmail.com>
* Docs: modify guides README with links to the available guides
* Add TestEntityBuilder for building test entity instances populated by random values
* Improve TestEntityBuilder for emails, BigDecimal precision/scale, protected method allow overriding
* Improve TestEntityBuilder for emails, use PersonOther
This Pull Request aim to fix the problem of DBJSONB dirty detection listed in #3129 which was due to PostgreSQL JSONB key reordering while storing value.
This cause Ebean to mark @DbJsonB properties as dirty on every load (triggering unnecessary UPDATEs and version increments) because the raw DB JSON key order differed from Jackson's serialization order.
Currently, Ebean is using CRC32 Checksum to compare but it is field ordering-dependent.
Introduce JsonContentHash:
A streaming order-independent structural hash of JSON content using Jackson's JsonParser.
Object keys are combined with commutative addition (a + b == b + a) so key ordering does not affect the hash, while array elements use positional hashing to preserve semantic ordering.
The hash uses FNV-1a for strings and MurmurHash3's fmix64 finalizer (both public domain) for mixing, producing a 64-bit hash with strong avalanche properties.
Changes:
- Add JsonContentHash utility (streaming, zero allocation, O(n) time)
- SourceMutableValue: use fast string equality with canonical hash fallback
- ChecksumMutableValue: replace CRC32 with JsonContentHash (also upgrades collision resistance from 2^32 to 2^64)
- No API changes, no schema changes, readSet() untouched
Docker changed and that broke how ebean-test-containers detected the
currently assigned port for a container. That was fixed in 7.18 but
thinking its a good idea to mark that relatively important bug fix
with a bump of the major version to 8.0.
Everyone using ebean-test-containers should consider updating the
ebean-test-containers dependency to 8.0 or 7.18 (both have the fix).
As per https://github.com/ebean-orm/ebean/discussions/3720
```
@Column
ZonedDateTime zonedDateTime2;
```
... resulting in DDL generated as `timestamp(255)`. This is
occurring when the JPA dependency is used like:
jakarta.persistence:jakarta.persistence-api:3.2.0
rather than using the transitive dependency that ebean includes.
Workaround:
Remove the jakarta.persistence:jakarta.persistence-api:3.2.0 dependency.
Fix:
The fix here is to use a timestamp type that has a maximum precision.
When a precision/length is specified greater than the maximum precision
then the fallback type is used which is `timestamp` without any precision.
robin.bygrave