Noting that value() currently calls through to getValue() hence
this is no real change. This is done because value() is also
a public method Property.value() [and this should probably
change to use getValueIntercept() rather than getValue()]
- captureMicros is the time taken to capture the specific query plan
- whenCaptured is the time when the bind values were taken
The DefaultQueryPlanListener logging will include these in the
output it logs
Can use this property to specify a mirror to use for test images when running in CI
Currently, we assume that for local builds we actually prefer to not use the mirror (for Arm64 support etc)
In theory no is customising these classes and probably should have their own copy of them if
they are doing do. Thus making these types final and package protected.
In DatabaseConfig.isAutoLoadModuleInfo() it only used the querybean generated class registration is classes.isEmpty(). Changing this so that it only uses the loadModuleInfo flag.
This means, unless loadModuleInfo is set to false the classes that register with ebean will be a combination of both the explicitly registered ones plus the classes from the querybean generated EbeanEntityRegister.
In addition, this changes the classes from List to Set.
As noted in comments in #2952
In the internals of SaveManyBeans we have:
- BUG: the deleteByParentId is hard delete and does not care for soft delete
- YUK: internally we have 3 ways of performing the orphan removal when we really want 2
This change fixes the BUG and fixes the YUK. It does this by removing the special case at: https://github.com/ebean-orm/ebean/blob/ebean-parent-13.11.3/ebean-core/src/main/java/io/ebeaninternal/server/persist/SaveManyBeans.java#L347-L350 ... and replacing it with the more common orphan removal code used when we do not have BeanCollection modifications.
The result of this change is that in SaveManyBeans internals we get back to have 2 ways to remove orphans.
- A BeanCollection with modifications: Orphans explicitly deleted using the known elements removed from the collection
- All other cases: Orphans as everything NOT in the collection that is going to be updated
orphanRemoval was not occurring when a loaded bean had a collection
replaced by a new BeanCollection (as opposed to a vanilla collection
like java.util.ArrayList).
Json marshalling a collection puts beans into BeanCollection and this
is part of the test that reproduced this issue.
robin.bygrave