Scott reported https://hibernate.atlassian.net/browse/HHH-12912 recently
and I was wondering if you could take a look at it, considering you worked
on the new CDI features of 5.3.
Asking for help as it would be nice to have a fix for WF 14 (released at
the end of this month) and time flies.
If you have some time to fix the issue or give us some guidance on the best
way to fix it, that would be helpful.
We just released Hibernate Validator 6.0.12.Final: the main change was made
to the CDI integration to fix a startup time regression. Please take a
closer look at the announcement if you're using CDI with Hibernate
The full announcement is here:
Have a nice day!
>From what I can see, the HQLQueryPlan objects are rather big, mostly due to
the sqlAst element of the QueryTranslators.
They can consume a fair amount of memory when you have a lot of HQL queries.
We need at least some of the information collected by the AST but I'm
wondering if we really need to keep all the AST information in memory once
the query has been parsed and the SQL query generated.
The purpose of this email is mostly to know if this element has been
accounted for in 6 development?
I haven't checked if it would be doable to improve the situation without
breaking too much stuff in 5.x.
we have these new databases running on AWS now:
- SQL Server Express Edition 14.00.3015.40.v1
- Oracle Standard Edition Two 220.127.116.11.v12
CI jobs are setup for Hibernate ORM to watch the master branch;
connection settings are committed in ORM's upstream.
See the usual matrix configurations in the sources if you need
details, or look at the job configurations.
Jobs are not looking too bad but there are a couple of failures which
will need investigation:
I have not setup email notifications, please enlist yourself if you're
interested in actively watching these.
Please be mindful of the restrictions:
- can't connect from home.
- there's nothing preventing multiple jobs to share these database so
don't enable any other jobs to use them - at least until we figure out
a reliable locking strategy.
I suspect time sharing is going to be the best answer - considering
we've lived fine without them for months, it should be ok to not run
them all the time.
I'm setting up some new Oracle integration tests on ci.hibernate.org,
and we're having again a similar issue to what we had with SAP HANA:
- some JDBC drivers can not be distributed freely
- we do not want to allow the Hibernate ORM build to load
dependencies from a local Maven repository
So I'm introducing a new (optional) environment variable described on:
This implies that if you were running these tests locally you will
need to adjust; I hope it's not too inconvenient.
N.B. the `jdbcDependency` attribute for the matrix configuration needs
to change to match the jar name. I'll commit the change for Oracle