6.0 - Dialect "initialization" proposal
by Steve Ebersole
Another change that has been discussed for a long time has been adding the
ability for Dialects to initialize themselves (or some "environment"
delegate) based on database/driver info including version info. The idea
would be to get out of having to define new Dialects just for some minor
update in a database or driver that Hibernate needs to be aware of - the
Dialect would be allowed to make that distinction itself based on access to
this info.
As hinted above, I am not sure yet if the best approach to this is to have
the Dialect configure itself (least disruptive) or have it configure some
"environment" (an expanded JdbcEnvironment maybe). But regardless, the
idea is the same.
The proposal centers around 2 contracts:
1. Dialect itself and some "Dialect#initialize" method
2. A way to give Dialect#initialize access to the needed information.
Let's start with (2) as it is the more defined. The basic idea would be
similar to the existing
`org.hibernate.engine.jdbc.dialect.spi.DialectResolutionInfo` contract.
The initial idea is something like
https://gist.github.com/sebersole/5af5bc5456701054632dd0eb65403505
For (1) there is still the question of whether Dialect#initialize affects
the Dialect itself or generates some "environment" object. But assuming
that it affects the Dialect itself, we would have something as simple as:
DatabaseInformation dbInfo = resolveDatabaseInformation(...);
Dialect dialect = resolveDialect( dbInfo );
dialect.initialize( dbInfo );
Or if we decide it should produce an environment object, something like:
DatabaseInformation dbInfo = resolveDatabaseInformation(...);
Dialect dialect = resolveDialect( dbInfo );
TheEnvironment env = dialect.initialize( dbInfo );
To note, we pass DatabaseInformation into #resolveDialect because it needs
some of that info (database-name / driver-name mainly) to decide on the
Dialect.
The end game here is that we would have single Dialects per database. E.g.
we'd have just:
1. OracleDialect
instead of:
1. OracleDialect
2. Oracle8iDialect
3. Oracle9Dialect
4. Oracle9iDialect
5. Oracle10gDialect
6. Oracle12cDialect
7. ...
9 years
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?
9 years
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
9 years
@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
9 years
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
9 years
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
9 years
