[ORM] EhCache 3 and JCache
by Emmanuel Bernard
Hello guys,
(I meant to send that almost a month ago, apologies Louis).
I’ve met Louis Jacomet from Ehcache at Devoxx France and we discussed how to restart the progress around JCache and EhCache 3 integration.
Louis is willing to step up to make these a reality but will need a bit of help to ramp up knowledge wise. Let me list the key subjects.
== JCache
I think Sanne has the info somewhere in his brain, what is the status of the current code? Any detail on what was missing? It would be nice to drive this one home.
== Ehcache 3
Ehcache 3 has been out recently and it would be nice to get an integration. The API is very different.
There are a few options:
1. make the JCache support extensible to build upon it and use Ehcache specific features when necessary or useful. Ehcache 3 is a JCache implementation.
2. create an new module dedicated to Ehcache 3 and go for it from scratch basically
3. change the Ehcache module and move it from v2 to v3
1. might be the conceptual nicest but it’s unclear how doable that is
2. vs 3. is about migration path for users and whether we consider it a “breaking change” in a 5.x series
== Doc and pointers
As I said, Louis know Ehcache well but needs some input to step into the magic world of second level caching in Hibernate ORM. Things like where is the code, how to test it, is there a doc or an example of a well written one etc.
Can someone give him a hand?
Emmanuel
8 years
HHH-10888
by Gail Badner
Currently, Hibernate's implementation of
javax.persistence.metamodel.PluralAttribute#isAssociation always returns
true. I haven't found anything in JSR 338 (yet) that refers to an element
collection as an association.
I don't see a good definition of "association", but the term is used with
respect to entities. I also see examples of @ElementCollection with
@AttributeOverride, but none with @AssociationOverride.
The change suggested in HHH-10888 is to have
PluralAttributeImpl#isAssociation return true only for one-to-many and
many-to-many. I believe this is correct, but it breaks a couple of tests
that specifically check if an element collection is an association.
I wanted to pass this by you in case I'm missing something here.
Please take a look at the pull request to see the fix and the required test
changes. [1]
Thanks,
Gail
https://github.com/hibernate/hibernate-orm/pull/1447
8 years
Non-final dependencies in hibernate-core.gradle
by Gunnar Morling
Hi,
I noticed that a preview release of CDI is specified as dependency for the
ORM core module: "javax.enterprise:cdi-api:1.1-PFD [1].
Is there a reason for using this specific one, or can we change it to the
Final (version "1.1")? Similarly for Weld
("org.jboss.weld:weld-core:2.0.0.Beta6") and EJB API
("org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:1.0.0.Alpha2").
I can send a patch to change it, just wanted to be sure it's nothing
intentional.
Thanks,
--Gunnar
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/hib...
8 years
Hibenrate-orm migration guides in one landing page
by Vlad Mihalcea
Hi,
I've seen questions on our forum and SO related to migration from 3.x to
5.x,
and users are complaining that it's difficult to follow the migration
guides since they are scattered among hibernate.org and GitHub.
Emmanuel pointed out that in Hibernate Search we have a single migration
page:
http://hibernate.org/search/documentation/migrate/
I find this a very good idea, and I think we should follow the same trend.
So, I think we should have a new migration folder path under
hibernate-orm/documentation:
http://hibernate.org/orm/documentation/migrate/
The migration guides can still be written in Asciidoctor, as on GitHub, and
during release, we copy this folder to hibernate.org.
As for the hibernate.org landing page, we'll have to add a new link only
when we deploy a new version, which, even if we can't automate it, we can
do it after the release.
Let me know what you think?
Vlad
8 years
