The issue fixed here is a timing one where the parent bean is being updated.
The updated parent bean has its internal state reset before the cascade down
to the SaveManyBeans where for this case it needs to identify is the 'vanilla'
collection has set (via setChildren(new ArrayList()).
This fix is a change that for updated beans the dirtyProperties is always obtained
and then use this for the isChangedProperty() check.
This change is that findFutureCount, findFutureList, findFutureIds do not trigger a flush on BatchedPstmtHolder.
This is to address the possible ConcurrentModificationException that could occur at BatchedPstmtHolder.closeStatements(BatchedPstmtHolder.java:153)
Using SqlUpdate or an ORM Update query clear the appropriate part of
the PersistenceContext. The effect is that ORM queries executed after
a bulk update will effectively load a fresh copy of the data from the
database and will not reuse an instance from the persistence context
if the bean in question had already been loaded.
When using DatabaseBuilder.readOnlyDatabase(true) then
ebean will:
- Set the DataSourceBuilder to use autoCommit=true and readOnly=true
- Use the same DataSource instance for both dataSource and readOnlyDataSource
This is to simplify the setup/configuration for creating a Database that
will only have read-only use.
Note that readOnly=true is a JDBC hint and for example H2 database effectively
ignores that hint where as Postgres will enforce the read-only true nature.
That is, existing code using DataSourceConfig has access to the getter
methods of DataSourceConfig. The DataSourceBuilder interface only has
the setter methods and DataSourceBuilder.Settings has both getters and
setter methods.
That is, the refactor to extract the DataSourceBuilder interface also
split off the getter methods to the DataSourceBuilder.Settings interface
(because most of the time when using the builder we only need the
setter methods and effectively hiding the getter methods behind the settings()
is useful to simplify the API for users).
So DatabaseBuilder.Settings has all the getters for code looking to read
the configuration that has been set. So DatabaseBuilder now just has the
setter methods.
Use DatabaseBuilder.settings() to access the settings and read the config
that has been set.
First step in migrating the ebean-datasource API to use builder pattern.
DataSourceConfig (concrete type) migrating to DataSourceBuilder (interface).
A followup step will deprecate the use of DataSourceConfig.
The loadMode ends up as a suffix to some query metrics.
For example "foo.findIt_baz(+lazy)", and the (+lazy) part isn't safe/friendly to tools
like Grafana. So change to instead of (+lazy) use __lazy.
Rob Bygrave