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.
This change is to reduce PUTs causing cache pollution where
changes that are rolled back are PUT into the bean cache.
Effectively remove the isSkipCacheExplicit() feature and just
use the existing isSkipCache(). This means that skipCacheAfterWrite
is used and PUTs after a database write/insert/update/delete are
effectively skipped.
The change that moved the filterMany predicates to the join had an
issue that extra joins may be needed to support those predicates.
Prior to this change, the extra predicates where effectively just
added to the end of the joins, rather than as a "child" node in
the SqlTreeNode tree.
This fix is in SqlTreeBuilder, where the list of top level extra
joins are first tried to be added as a child to a parent node, and
only if we can't find the parent added at the end.
This is to support the use case where other logic is used to determine if a query
should be "forced" to use the master data source or not, and so it's easier to
pass that as a boolean to the usingMaster() method.
* #3695 Behaviour change: findSingleAttribute() to throw when multiple rows returned by query
On the plus, this makes the behaviour consistent with all the other findOne() methods (ORM, DTO, SqlQuery) and this very much feels like buggy behaviour [to just get the first result and ignore any subsequent results in the ResultSet]
On the negative of merging this bug fix, any application code relying on the existing behaviour with this fix will break and throw a NonUniqueResultException at RUNTIME (not ideal). However, for these cases where the application now throws an exception, people might not be aware that they were relying on this behaviour and this exception could be useful to highlight that (a potential non-deterministic query result was being used and a potential source of bugs was being).
* Change SqlQuery + Mapper + findOne() also to throw NonUniqueResultException
* Problem with filterMany
* Missing id
* Other test
* Fix
* Update TestQueryFilterMany.java
* #3706 Bug fix and change filterMany to put predicates into JOIN clause, Fix for #3626
* Fix tests for Postgres, Oracle, Sql Server
---------
Co-authored-by: Roman Parshikov <promansew@gmail.com>
- Add AggregateFormulaContext with ability to override the default via DatabaseBuilder
- Add group_concat, string_agg, listagg to set of known aggregation functions
* Version 16.1.0
* #3682 @Aggregation is applied to query if entity also has a @Lob column
The underling issue was that Aggregation columns should have been marked as default LAZY. This impact was only hit when @Lob column are included which by default lazy fetched, and that means the default select clause determined.
* Version 16.1.0
* Improve javadoc for Query setUseQueryCache() and unmodifiable
Since 16.x a query using the query cache returns unmodifiable object graphs.
* #3664 Fix / support for extra JoinColumns on ManyToOne
Allows for extra JoinColumns on ManyToOne. The extra JoinColumn(s) are
expected to be useful for the case of table partitioning where the extra
join column is used to partition the table. In the test case, the partition
column would be the org_id column and common to both tables (same partition key).
* #3664 Fix / support for extra JoinColumns on ManyToOne
Allows for extra JoinColumns on ManyToOne. The extra JoinColumn(s) are
expected to be useful for the case of table partitioning where the extra
join column is used to partition the table. In the test case, the partition
column would be the org_id column and common to both tables (same partition key).
* #3664 Extend test
* #3664 Tidy up test
* Use autocommit false with findIterate for Postgres
* Use autocommit false with findIterate for Postgres
* Use autocommit false with FindDto queries for Postgres
* Use autocommit false with SqlQuery findIterate queries for Postgres
* Ensure that TransactionFactory.createReadOnlyTransaction() returns an ImplicitReadOnlyTransaction
This change changes TransactionFactoryTenant.createReadOnlyTransaction() to return a ImplicitReadOnlyTransaction, as that is now used to support Postgres use of cursors with findIterate style queries.
Rob Bygrave