[Hibernate-JIRA] Created: (HHH-5171) Allow usage of standalone @JoinFormula annotation
by Sharath Reddy (JIRA)
Allow usage of standalone @JoinFormula annotation
-------------------------------------------------
Key: HHH-5171
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5171
Project: Hibernate Core
Issue Type: Improvement
Components: annotations
Affects Versions: 3.6
Reporter: Sharath Reddy
Assignee: Sharath Reddy
Fix For: 3.6
If there is a single-column join (based on formula) between 2 entities, it is overkill to wrap the @JoinFormula within a @JoinColumnsOrFormulas annotation:
@ManyToOne
@JoinColumnsOrFormulas(
{ @JoinColumnOrFormula(formula=@JoinFormula(value="SUBSTR(product_idnf, 1, 3)", referencedColumnName="product_idnf")) })
The above annotation is powerful, because it gives us the flexibility of using an arbitrary combination of columns and formulas for the join, but in this case it is redundant.
If would be easier to just specify like this:
@ManyToOne
@JoinFormula(value="SUBSTR(product_idnf, 1, 3)", referencedColumnName="product_idnf")) })
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[Hibernate-JIRA] Created: (HHH-5042) TableGenerator does not increment hibernate_sequences.next_hi_value anymore after having exhausted the current lo-range
by Guenther Demetz (JIRA)
TableGenerator does not increment hibernate_sequences.next_hi_value anymore after having exhausted the current lo-range
-----------------------------------------------------------------------------------------------------------------------
Key: HHH-5042
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5042
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-CR-2, 3.5.0-CR-1, 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2, 3.5.0.Beta-1
Environment: Hibernate: 3.5 , db: HSQLDB (not relevant)
Reporter: Guenther Demetz
Priority: Critical
Attachments: TestTableGenerator.java
This bug is new in 3.5
In version 3.5 class MultipleHiLoPerTableGenerator.java was modified introducing a
new increment variable
IntegralDataTypeHolder value;
along with
int lo;
The problem in the new code is that only value get's incremented whilst variable lo
is still used to check when a new hiVal must be obtained.
if ( lo > maxLo ) {
IntegralDataTypeHolder hiVal = (IntegralDataTypeHolder) doWorkInNewTransaction( session );
as lo is never incremented, MultipleHiLoPerTableGenerator continues to deliver numbers without ever update
hibernate_sequences.next_hi_value on the database (only one unique update is propagates at the first insert)
This lead to duplicate keys as soon another session from another sessionfactory tries to insert new objects on the concerning table.
Please see attached testcase.
IMPORTANT ADVICE TO RUN THE TESTCASE:
as the testcase uses 2 sessionfactories hibernate.hbm2ddl.auto=create cannot be used!!
Schema has to be exported separately and the testcase must run without hbm2ddl.auto property!
Here the schema for HSQLDB:
create table A (oid bigint not null, name varchar(255), version integer not null, primary key (oid), unique (name))
create table hibernate_sequences ( sequence_name varchar(255), sequence_next_hi_value integer )
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[Hibernate-JIRA] Created: (HHH-4991) ManyToMany table not joined due to max_join_depth parameter, results to SQL exceptions
by Sergii Novotarskyi (JIRA)
ManyToMany table not joined due to max_join_depth parameter, results to SQL exceptions
--------------------------------------------------------------------------------------
Key: HHH-4991
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4991
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.5.0-CR-2
Environment: Hibernate 3.5.0-CR-2, MacOS X, MySQL 5.1
Reporter: Sergii Novotarskyi
Attachments: Example.zip
*max_join_depth* parameter prevents Hibernate from joining one end of ManyToMany relationship when using Criteria API, if the relationship is "far" enough from the root entity.
{quote}
Criteria c = session.createCriteria(SubEntity.class)
.createAlias("entity", "e") // ManyToOne, inner join
.createAlias("e.entity", "ee") // ManyToOne, inner join
.createAlias("ee.sides", "s") // ManyToMany, inner join + left outer join
.setProjection(Projections.count("id"))
.add(Restrictions.ne("s.data", "abc"));
{quote}
When *max_join_depth* is set to *2* (default) the above example generates following SQL query
{quote}
select count(this_.sub_id) as y0_ from SubEntity this_
inner join SubMainEntity e1_ on this_.submain_id=e1_.submain_id
inner join MainEntity ee2_ on e1_.main_id=ee2_.main_id
inner join MainSide sides7_ on ee2_.main_id=sides7_.main_id
where s3_.data<>?
{quote}
The query, naturally, throws the "Unknown column 's3_.data' in 'where clause'" exception.
Expected query would be
{quote}
select count(this_.sub_id) as y0_ from SubEntity this_
inner join SubMainEntity e1_ on this_.submain_id=e1_.submain_id
inner join MainEntity ee2_ on e1_.main_id=ee2_.main_id
inner join MainSide sides7_ on ee2_.main_id=sides7_.main_id
left outer join SideEntity s3_ on sides7_.side_id=s3_.side_id
where s3_.data<>?
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[Hibernate-JIRA] Created: (HHH-5125) The annotations @Entity and @MappedSuperclass used in one class produce a nullpointerexception
by Simone Rodenbach (JIRA)
The annotations @Entity and @MappedSuperclass used in one class produce a nullpointerexception
----------------------------------------------------------------------------------------------
Key: HHH-5125
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5125
Project: Hibernate Core
Issue Type: Bug
Components: annotations
Affects Versions: 3.5.1
Environment: MS SQL Server
Reporter: Simone Rodenbach
Priority: Critical
Caused by: java.lang.NullPointerException
at org.hibernate.cfg.ClassPropertyHolder.addPropertyToMappedSuperclass(ClassPropertyHolder.java:133)
at org.hibernate.cfg.ClassPropertyHolder.addPropertyToPersistentClass(ClassPropertyHolder.java:118)
at org.hibernate.cfg.ClassPropertyHolder.addProperty(ClassPropertyHolder.java:98)
at org.hibernate.cfg.ClassPropertyHolder.addProperty(ClassPropertyHolder.java:81)
at org.hibernate.cfg.annotations.PropertyBinder.bind(PropertyBinder.java:246)
at org.hibernate.cfg.annotations.PropertyBinder.makePropertyValueAndBind(PropertyBinder.java:200)
at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1979)
at org.hibernate.cfg.AnnotationBinder.processIdPropertiesIfNotAlready(AnnotationBinder.java:762)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:726)
at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:636)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:359)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1377)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:954)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[Hibernate-JIRA] Created: (HHH-5322) Regression in PersistenceUtilHelper
by Jürgen Zimmermann (JIRA)
Regression in PersistenceUtilHelper
-----------------------------------
Key: HHH-5322
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5322
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.5.3
Reporter: Jürgen Zimmermann
After upgrading from 3.5.2 to 3.5.3 I get the stacktrace below. When using 3.5.2 everything works fine (in combination with Hibernate Validator 4.1.0.CR1 and 4.1.0.Beta2). Due to the "Caused by" in the stacktrace I assume that it's an issue of Hibernate itself, and not of Hibernate Validator.
In an entity class I've placed the JPA and validation annotations at the Java *fields*, and there is also one validation annotation placed at a *method*:
@AssertTrue(groups=NoAttrGroup.class,
message="{kundenverwaltung.kunde.password.notEqual}")
public boolean isPasswordEqual() {
if (password == null)
return passwordWdh == null;
return password.equals(passwordWdh);
}
The stacktrace:
javax.validation.ValidationException: Call to TraversableResolver.isReachable() threw an exception
at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:766)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:324)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForNonDefaultGroup(ValidatorImpl.java:305)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:245)
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:210)
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:119)
at de.hska.kundenverwaltung.service.KundenverwaltungImpl.validate(KundenverwaltungImpl.java:252)
at de.hska.kundenverwaltung.service.KundenverwaltungImpl.createKunde(KundenverwaltungImpl.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor.invoke(AfterReturningAdviceInterceptor.java:50)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at $Proxy79.createKunde(Unknown Source)
at de.hska.test.KundenverwaltungTest.createPrivatkunde(KundenverwaltungTest.java:310)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: javax.persistence.PersistenceException: Unable to find field or method: class de.hska.kundenverwaltung.domain.Privatkunde#passwordEqual
at org.hibernate.ejb.util.PersistenceUtilHelper$MetadataCache.findMember(PersistenceUtilHelper.java:203)
at org.hibernate.ejb.util.PersistenceUtilHelper$MetadataCache.getMember(PersistenceUtilHelper.java:178)
at org.hibernate.ejb.util.PersistenceUtilHelper.get(PersistenceUtilHelper.java:91)
at org.hibernate.ejb.util.PersistenceUtilHelper.isLoadedWithReference(PersistenceUtilHelper.java:83)
at org.hibernate.ejb.HibernatePersistence$1.isLoadedWithReference(HibernatePersistence.java:93)
at javax.persistence.Persistence$1.isLoaded(Persistence.java:83)
at org.hibernate.validator.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:62)
at org.hibernate.validator.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:94)
at org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:47)
at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:757)
... 57 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months
[Hibernate-JIRA] Created: (HHH-5385) Make Hibernate wrapped objects more serializable friendly
by Bill DeCoste (JIRA)
Make Hibernate wrapped objects more serializable friendly
---------------------------------------------------------
Key: HHH-5385
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5385
Project: Hibernate Core
Issue Type: New Feature
Reporter: Bill DeCoste
Make Hibernate wrapped objects more serializable friendly. LazyInitializationException's are the devil when trying to serialize an object graph. A mechanism for being able to serialize an uninitialized collection or object that returns null or an empty set is highly preferable to the existing behavior that currently causes the infamous LazyInitializationException explosion.
- Use case: We'd like to abridge certain object graphs when serializing objects for representation. For instance, I might want to get all Avatar names, but not the entire object graph of every avatar in the system. We currently have a mechanism that accomplishes this, but at substantial cost due to the fact that we must purposefully fetch the entire object, then hack away what we don't want to send. We'd rather leave sub-collections, etc., uninitialized/unfetched and be able to serialize without error. Another way to express it is that we'd like the option to ignore and skip uninitialized collections (leaving them null/empty) when serializing an object.
- Related issue: We currently have some code to work around a perceived issue where an empty collection always returns a LazyInitializationException if left in the object graph. We have found that we have to explicitly null-out empty collections in an object before serialization. We'd like to not have to worry about this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 2 months