Changing group ids from org.hibernate to org.hibernate.{project}
by Gunnar Morling
Hi,
I just stumbled across HHH-11153 ("Rename published groupId from
org.hibernate to org.hibernate.orm"), scheduled for ORM 6.0.0.Alpha1.
I think that's a great idea and would suggest we do the same for Hibernate
Validator and Search in their respective 6.0 releases:
org.hibernate.validator and org.hibernate.search (for OGM we used
org.hibernate.ogm from the beginning).
Any concerns?
--Gunnar
7 years, 11 months
Hibernate Search: new 5.7 branch, dual streams development!
by Sanne Grinovero
I've promoted my "ORM 5.2 upgrade preview" pull request as upstream
branch "5.7",
just after having it rebased on the freshly baked tag: 5.6.0.Beta3
This implies we have now two active streams of development for
Hibernate Search (!);
we still have just one mission: finish 5.6 and its Elasticsearch support.
We'll have to occasionally forward-port patches from 5.6 to 5.7; I
propose to keep the work focused on 5.6 and intentionally ignore 5.7:
then when the next 5.6.0.CR1 release happens one volunteer takes the
full range of commits 5.6.0.Beta3-5.6.0.CR1 and applies it as a single
block on 5.7.
On branch 5.7 we'll exclusively apply patches to keep up with ORM upgrades.
Hopefully there won't be too many conflicts: please keep this all in
mind when tempted by some "cleanup refactoring". We'll have fun later
;-)
For those wondering why: finishing 5.6 was taking more than expected,
and many users need an Hibernate Search version compatible with ORM
5.2.0+ (while version 5.6 was aiming at ORM 5.1.x and we can't leave
those users without any compatible version can we?).
As soon as the Elasticsearch integration is satisfactory we'll return
to more healthy time-window sprints and consequentially regular,
periodic releases.
Next step: finalize the simultaneous release of versions:
- 5.6.0.Beta3
- 5.7.0.Alpha1
- 5.5.5.Final
Thanks,
Sanne
7 years, 11 months
Multi-tenancy test helpers
by Sanne Grinovero
Hi all,
in Hibernate Search we have a test helper to setup Hibernate ORM with
multi-tenancy and export the schema's we need for testing.
It looks like:
- https://raw.githubusercontent.com/hibernate/hibernate-search/d29f560c89e6...
The problem is I used Hibernate ORM's internals, and this little
helper keeps breaking.
Could we have such an utility provided by ORM?
Also wondering if "test helpers" such as this one could be useful to
end users; it would be nice to publish such helpers and maintain their
API as stable as any other API.
For example now to have Hibernate Search switch from ORM 5.2.1 to
5.2.2 it requires code changes - luckily just on tests! - but it still
bothers me as it means we can't automatically test a version X of
Search towards a full-range of micro releases of ORM 5.2.x.
Thanks,
Sanne
7 years, 11 months
Adding a Byte Buddy byte code provider to Hibernate
by Rafael Winterhalter
Hello everybody,
I was wondering how big the chances are to get a Byte Buddy bytecode
provider into Hibernate? Byte Buddy has matured a lot over the last two
years and it aims a lot on performance what is something Hibernate could
benefit of. There are comparion charts posted on the Byte Buddy webpage. As
a bonus, Byte Buddy is already ready for Java 9 and gives a lot of features
for free, for example generic meta data retention and a possibility to
retain annotations on subclassed types and overridden methods.
I have written a simple proof of concept here:
https://github.com/raphw/hibernate-bb without having tested it - I did not
implement the fast class providers as I have learned after a lot of
benchmarking that those do not improve performance on Java 8+ VMs anymore.
Using such fast-classing rather pollutes the code cache than bring any
benefit. The only advantage with code generation in this field comes when
avoiding boxing what is not the case. But of course, I can implement
something in Byte Buddy to apply such a fast-class mechanism.
Let me know what you think. I am more then happy to help you with
implementing such a provider. Other frameworks such as Mockito already use
Byte Buddy on a large scale and made good experiences with it.
Best regards, Rafael
7 years, 11 months
Dialect#remapSqlTypeDescriptor
by Steve Ebersole
TLDR: Should we adjust to allow Dialect to know the "context" of where the
remapping is requested?
Ah Oracle...
So this comes from the fact that Oracle does not support a BOOLEAN
datatype. Well kind of. It does not support a BOOLEAN datatype in its
"SQL engine". However, in PL/SQL it does in fact support a BOOLEAN
datatype. Which comes into play when we talk about calling functions and
procedures: the arguments and returns can in fact be a BOOLEAN.
As far as I know, Oracle is the only database with this type of
inconsistency in its type system. But the question is whether we want to
pass along some kind of information regarding the context (SQL v function v
procedure) to the Dialect#remapSqlTypeDescriptor.
You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
illustration of how this impacts applications. And if you look through the
comments you can see the kind-of-crazy workaround needed.
7 years, 11 months
