Please do not merge to ORM 5.3
by Guillaume Smet
Hi,
Please do not merge anything to ORM 5.3 for now, we need to have a
discussion about what we merge there.
Thanks!
--
Guillaume
8 years
BlobProxy, Reducing the amount of Proxies we rely on at runtime
by Sanne Grinovero
I'm trying to understand if we could remove some of the usages of
`java.lang.reflect.Proxy`.
Clearly it's a long journey and maybe we will never be able to remove
them all, but I would at least want to try avoiding most of their neet
at runtime - limiting their usage at bootstrap/configuration or other
similar "one time" contexts.
We're all aware that these proxies have not been introduced lightly:
most are necessary or very useful; at least useful enough to prefer
having them to not having them; surely the tradeoffs have been
considered.
So what I'm trying to understand now is if all the tradeoffs made in
the past are still actual; some of the related code is > 10 years old;
I could use some help with evaluating what could be safely removed.
One example: org.hibernate.engine.jdbc.BlobProxy has the following comment:
"We use proxies here solely to avoid JDBC version incompatibilities."
Today we require Java8 as baseline, and the `java.sql.Blob` did not
change in any more recent JDK (I just thouroughly diff-ed the
JDK8,9,10,11,12 on this package using Gunnar's jdk-api-diff tool).
Would that be a reasonable candidate to replace the Proxy usage with a
plain implementation of the relevant interfaces? Clearly this implies
I'm betting that future JDKs will not break this again, still I'd
rather cleanup this usage today.
1 - Could I go ahead with that?
2 - Any more such cleanups come to mind?
Thanks,
Sanne
8 years
Releasing Hibernate ORM 5.2.18.Final?
by Guillaume Smet
Hi,
So, it's been a long time since we last released the ORM 5.2 branch and
some people are asking about it, some of them with good reasons not to
upgrade to 5.3.
I think we are making it something big because we wanted it to be THE last
5.2 release and this ends up in it not being released at all.
Also, we have a lot of other things to do, which doesn't help.
I propose the following plan:
- starting September 1st, I'll go through the 5.3 fixes and see what can be
easily backported - we already have important fixes in 5.2.18 so if some
issue is not easily backportable or worth it, I'll skip it altogether and
wait for someone to complain vocally about it;
- I'll wrap up a 5.2.18 by September 14th;
- if we need one more after that, I'll do another release.
If you have a 5.3 fix you absolutely want in 5.2.x, please be vocal about
it because there's a good chance I will be pretty aggressive in not
backporting the bugfixes we pushed to 5.3 recently (e.g. not cherry-picking
gracefully -> not in 5.2.18).
The idea is to let Gail focus as much as possible on the still opened 5.1
-> 5.3 regressions.
Does everybody agree with this plan?
--
Guillaume
8 years
CDI related issue
by Guillaume Smet
Hi Steve,
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.
Thanks!
--
Guillaume
8 years
Reducing the memory usage of HQLQueryPlan
by Guillaume Smet
Hi,
>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.
Thanks.
--
Guillaume
8 years
Now testing SQL Server and Oracle DBs on the public facing ci.hibernate.org
by Sanne Grinovero
Hi all,
we have these new databases running on AWS now:
- SQL Server Express Edition 14.00.3015.40.v1
- Oracle Standard Edition Two 12.1.0.2.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:
- http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-oracle/
- http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-mssql/
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.
Thanks,
Sanne
8 years
[!] Changing how to run tests with proprietary JDBC drivers: Oracle, HANA
by Sanne Grinovero
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:
- https://hibernate.atlassian.net/browse/HHH-12901
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
soon.
Thanks,
Sanne
8 years
