6.0 proposal - CollectionTuplizer
by Steve Ebersole
As part of removing most Type sub-types we are left with the question of
how to handle the role served by CollectionType. Andrea and I came up with
a proposal that not only serves that purpose but also allows a level of
customization we have so far not supported but which has been asked for a
few times (mostly as part of framework/language integration into Hibernate;
Ceylon, etc).
Here is the proposal:
/**
* Encapsulates collection type specific behavior/information
* <p/>
* NOTE : the name "tuplizer" was chosen as this really serves
* same logical purpose as the entity and component tuplizers
* do entities and components respectively.
*/
interface CollectionTuplizer<C> {
/**
* Access to the type of the collection. This
* is expected to be an interface. Used to create
* a registry against which we can resolve the
* reflected attribute type. E.g. an attribute
* defined as `List` would be resolved to the
* CollectionTuplizer that deals with lists
*/
Class<C> getCollectionJavaType();
/**
* Create an empty instance of the collection wrapper
*/
PersistentCollection<C> create(int anticipatedSize);
/**
* Wrap an existing "raw" view of the collection
*/
PersistentCollection<C> wrap(Object rawCollection);
/**
* Creates the representation of this plural attribute
* according to the runtime domain model view.
*/
<O> PluralPersistentAttribute<O,C,?> generatePluralAttribute();
// anytihng else? element comparator, etc?
}
Thoughts? Suggestions?
8 years, 1 month
JPA-SQL
by Gunnar Morling
Hi,
This might be interesting to some:
https://rapidclipse.atlassian.net/wiki/display/DOCEN/JPA-SQL.
It's an external DSL for writing queries which are translated into JPA
Criteria API queries then. There's a dedicated editor for that DSL,
with auto-completion etc. I.e. one should get the feel of writing
JPQL, but in a more comfortable manner (error detection right in the
editor, refactoring support etc.)
I haven't tried it out, but I think it's a nice idea. What's not clear
to me is though why this isn't JPQL proper; that's the "language
specification":
https://rapidclipse.atlassian.net/wiki/display/DOCEN/JPA-SQL+Language+Spe....
Perhaps only a sub-set of JPQL can be transformed into equivalent
Criteria API calls?
Cheers,
--Gunnar
8 years, 1 month
@org.hibernate.annotations.Index and NullPointerException in IndexOrUniqueKeySecondPass
by Laurent Almeras
Hello,
I encounter a NullPointerException in IndexOrUniqueKeySecondPass with
Hibernate 5.2.10.Final (stack at the end of mail).
It appears that problem seems to be linked to
@org.hibernate.annotations.Index (deprecated annotation) used in an
embeddable component, due to the following code that does not consider
that Index can be declared in an embedded field
(IndexOrUniqueKeySecondPass, l.75-76):
PersistentClass persistentClass = (PersistentClass)
persistentClasses.get( column.getPropertyHolder().getEntityName() );
Property property = persistentClass.getProperty( column.getPropertyName() );
I don't know if you are willing to work on this issue as:
* @org.hibernate.annotations.Index is deprecated for long
* Using @Index on an embedded field can be considered as tricky
But this used to work in previous Hibernate version (last known working
version: 5.1.2.Final)
On my side, replacing getPropertyHolder().getEntityName() by
column.getPropertyHolder().getEntityOwnerClassName() fix my problem.
PersistentClass persistentClass = (PersistentClass)
persistentClasses.get(
column.getPropertyHolder().getEntityOwnerClassName() );
Property property = persistentClass.getProperty( column.getPropertyName() );
Please let me know if you want to work further on this problem so that I
create an issue on Jira.
The encountered stack trace (spring controlled Entity manager):
Caused by: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'entityManagerFactory' defined in
com.rhonealpestourisme.sitra.core.common.config.spring.SitraCoreCommonJpaConfig:
Invocation of init method failed; nested exception is
java.lang.NullPointerException
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1628)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
at
org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:208)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1138)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1066)
at
org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:835)
at
org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:741)
... 54 more
Caused by: java.lang.NullPointerException
at
org.hibernate.cfg.IndexOrUniqueKeySecondPass.doSecondPass(IndexOrUniqueKeySecondPass.java:76)
at
org.hibernate.boot.internal.InFlightMetadataCollectorImpl.processSecondPasses(InFlightMetadataCollectorImpl.java:1621)
at
org.hibernate.boot.internal.InFlightMetadataCollectorImpl.processSecondPasses(InFlightMetadataCollectorImpl.java:1589)
at
org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:278)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:858)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:885)
at
fr.openwide.core.jpa.hibernate.ejb.InterceptorAwareHibernatePersistenceProvider.createContainerEntityManagerFactory(InterceptorAwareHibernatePersistenceProvider.java:51)
at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:353)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:370)
at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:359)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1687)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1624)
... 65 more
--
Logo <http://www.smile.fr/>
151 boulevard Stalingrad
69100 Villeurbanne
Tel : 04 26 68 95 00
Fax : 04 26 68 95 01
www.smile.fr <http://www.smile.fr/>
*Laurent ALMERAS*
Architecte technique
Email : laurent.almeras(a)smile.fr <mailto:laurent.almeras@smile.fr>
Tel : +33 4 26 68 95 03
bandeaux_mail
<http://information-systems.smile.eu/?utm_source=signature&utm_medium=emai...>
eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
8 years, 1 month
HHH-11791
by Christian Bongiorno
Now that java 8 supports named parameters it becomes possible (potentially
preferrable) to use constructor injection instead of circumventing
encapsulation to set values on private fields.
This shows itself as a potential win when integrating with Kotlin with
disallows the circumvention quite forcefully. Meaning: without constructor
injection the object needs setters. And, if it has setters then it's
mutable which is against best practices.
I propose optionally using constructor injection when marshalling an object
from data sources in a DB. I am willing to make the changes if I know they
can/will be incorporated.
Thoughts? Here is the ticket
https://hibernate.atlassian.net/browse/HHH-11791
8 years, 1 month
Migration path from 3.6 to 5.2
by Prasanth Mathialagan
Hi,
We have been using hibernate-orm in our application for a long time. The
version of hibernate we use is 3.6.10.Final. I know it is archaic. We would
like to migrate to the latest stable version (5.2) to reap the benefits of
new optimizations and features. Initially we thought about upgrading to
4.x. Since we are also doing Java 8 and Spring 4 upgrades, we have decided
that it would be better to migrate hibernate to 5.2 together.
I know it is not possible to migrate from 3.6 to 5.2 directly.I have
checked online for migration guides. But I am bit off about which path
should I take to migrate (eg. 3.6 to 4.3 to 4.5 to 5.2). Can someone help
me with figuring out minimum number of migrations from 3.6 to reach 5.2? I
would be grateful if you could point me to some resources
8 years, 1 month
Upgrade version of Hibernate - default_schema specificity
by Margot PIVA
Hello,
For the need of our project we had to upgrade the version of
Hibernate from 5.1.2.Final to 5.2.10.Final.
We referred to the changelog
to adapt our code and it worked perfectly well except that
Hibernate
couldn't find our schema event though it was declared on the
search_path of our PostgreSQL database
configuration (at user's level).
We observed that this behavior appeared from (and including) the version
5.1.4.Final,
and we supposed that it came from this bugfix :
https://hibernate.atlassian.net/browse/HHH-11023
Finally we found out
that we had to specify the default_schema directly to Hibernate and we
thought
that it would be favourable to point this necessity out.
8 years, 1 month
