Caused by: java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
at jdk.internal.util.Preconditions.outOfBounds(Unknown Source)
at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Unknown Source)
at jdk.internal.util.Preconditions.checkIndex(Unknown Source)
at java.util.Objects.checkIndex(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at io.ebeaninternal.server.persist.BatchedPstmt.profile(BatchedPstmt.java:132)
So the desire here is to better support sending metrics to Prometheus style metrics collectors that prefer CUMULATIVE metrics rather than DELTA based metrics.
To do this, expose additional MetaInfoManager.collectMetrics(reset) method.
In supporting this, the MAX value really does need to reset even with CUMULATIVE metrics and act more like a gauge as otherwise it becomes almost useless as the max value over the lifetime. So we need to adjust MAX to always reset and act like a gauge to be useful in this CUMULATIVE metrics reporting mode.
- ebean.version 17.2.0 -> 17.5.0 (minimum for TestEntityBuilder)
- avaje-inject 11.5 -> 12.5
- Add io.avaje:junit:1.8 bundle to test dependencies
- Remove .skipDataSourceCheck(true) from database config example
- Add note about Configuration DI wiring in Step 3
* Deprecate DatabaseConfig and DatabaseFactory, prefer Database.builder()
Deprecate the DatabaseConfig way of creating Database instance.
Migrate to use Database.builder().
* Deprecate DatabaseConfig and DatabaseFactory, migrate test code
* Use @Deprecated(forRemoval = true) on DatabaseConfig and DatabaseFactory
* Tidy up Database javadoc for deprecation
* Change [implicit] Lazy loading to be by TYPE rather than by PATH
We have some graph models where a common type (in the tests it is Label)
is used in many different *paths* of the graph. When we are loading via
*path* then all the loading of the Labels isn't in a single batch / load context
but instead split into different load contexts PER PATH.
This change, means that lazy loading operates by TYPE instead of by PATH.
In the tests, all the Labels are read via a single lazy loading query rather
that one lazy loading query per PATH, and this is more efficient.
* ImmutableBeanCache part 1
* ImmutableBeanCache part 2
* ImmutableBeanCache part 3 - add ImmutableBeanCaches
* ImmutableBeanCache - add propagation of caches to secondary queries
* ImmutableBeanCache - use and improve BeanDescriptor.merge() to positional
Using positional avoids the lookup by property name.
* ImmutableBeanCache - add unit testing with BeanDescriptorMergeTest
* ImmutableBeanCache - add testing for the further lazy loading on mutable beans
Also add doc / guides
* Add ImmutableCacheBuilder with underlying DefaultServerCache implementation
This provides a cache with maxSize, maxIdleSeconds, maxSecondsToLive
* Improve javadoc and doc / guides for ImmutableBeanCache
* Add cache invalidation for ImmutableBeanCache
* Use immutable cache direct hits for unmodifiable assoc-one refs
- add ImmutableBeanCache.getIfPresent() as a non-loading probe
- use immutable cache hits in AssocOneHelp / AssocOneHelpRefInherit
- avoid creating ref beans and merge/copy for unmodifiable cache hits
- keep existing mutable-query and miss/backfill behavior unchanged
* Enhance ProfileStream to support Open Telemetry
* Add ebean-opentelemetry module
* Add the sql query text as span attribute.
Note: This is a breaking API change here but I'm pretty confident
that no one is using the ProfileStream API - hmmm.
* Otel: Use the query label and transaction label in span name if available
* SpiProfileHandler: Change such that if service loaded, doesn't need ProfileConfig
---------
Co-authored-by: Rob Bygrave <robin.bygrave@gmail.com>
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.
Rob Bygrave