While not strictly compliant with the SQL specification, the MySQL, PostgreSQL and H2 support the use of select aliases in the GROUP BY clause. An obvious benefit is that produced SQL queries will be easier to read, because complex select expressions from aggregrate queries will have to be included in the group by clause as well. These can now simply reference the aliases of the respective columns for the tuple element. However, there is also a functional difference. For function invocations that have parameterized arguments, the query optimizer can't guarantee the that the function result between the selection projection and grouping process are equal. This results in an error because a value is projected which is not grouped by. An example where this for example becomes relevant, is when parameterizing TimeScaleDB's [`time_bucket_gapfill()`](https://docs.timescale.com/latest/api#time_bucket_gapfill-examples) function.
For example, using `time_bucket_gapfill()` one might want to produce a criteria query that produces the following SQL:
```sql
SELECT
time_bucket_gapfill(?, time, ?, ?) AS ts,
avg(tg) as tg
FROM iaqmeasurement
GROUP BY ts
ORDER BY ts;
```
When the alias is not used as grouping value, the query will yield an error:
```sql
SELECT
time_bucket_gapfill(?, time, ?, ?) AS ts,
avg(tg) as tg
FROM iaqmeasurement
GROUP BY time_bucket_gapfill(?, time, ?, ?)
ORDER BY ts;
```
Of course the parameter values can just be stored in a CTE as well, but I think we should consider support for variable refs in group by for DBMS dialects that support it. This pull request implements the feature equivalently to how its currently done for order by clauses, and only enables the feature for known supported dialects (H2, PostgreSQL and MySQL - based on [https://stackoverflow.com/a/3841804/2104280](https://stackoverflow.com/a/3841804/2104280)).
Jira: https://hibernate.atlassian.net/browse/HHH-9301
Co-authored-by: Sayra Ranjha <S.S.Ranjha@student.tudelft.nl>
- e.g. a datasource passed in the integration overrides map ought to effectively override JDBC-connection settings in `persistence.xml` (and vice-versa)
HHH-13432 - Have EntityManagerFactory expose persistence.xml `jta-data-source` element as a `javax.persistence.nonJtaDataSource` property
HHH-12323 - Update Statistics API and SPI based on changes to 2nd level caching changes
HHH-12416 - set up relocation for hibernate-ehcache
HHH-12417 - default strategy based on registrations with StrategySelector
test failure
HHH-12323 - Update Statistics API and SPI based on changes to 2nd level caching changes
HHH-12416 - set up relocation for hibernate-ehcache
HHH-12417 - default strategy based on registrations with StrategySelector
Basically reverted HHH-12416 and added basic support for Ehcache 2 again
HHH-12323 - Update Statistics API and SPI based on changes to 2nd level caching changes
- initial work on migrating hibernate-jcache to new SPIs including a more template-style approach to writing a RegionFactory (o.h.cache.spi.support)
HHH-12323 - Update Statistics API and SPI based on changes to 2nd level caching changes
- initial work on migrating hibernate-jcache to new SPIs including a more template-style approach to writing a RegionFactory (o.h.cache.spi.support)
Jan-Willem Gmelig Meyling
Sanne Grinovero
Steve Ebersole
Carsten Hammer
Andrea Boriero
Chris Cranford
Vlad Mihalcea
Guillaume Smet
Bruno P. Kinoshita