September 2012 - hibernate-issues

[Hibernate-JIRA] Created: (HHH-5845) Lazy Loading of audited entites with revision type 'delete'

by Jonas Schlaak (JIRA)

Lazy Loading of audited entites with revision type 'delete' ----------------------------------------------------------- Key: HHH-5845 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5845 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.6 Environment: Hibernate 3.5.6, Oracle 10 DB Reporter: Jonas Schlaak Two classes are given, and they are related via a OneToOne relationship: @Audited public class MyClass { @OneToOne @Cascade(value = CascadeType.ALL) private MyOtherClass otherClass; } @Audited public class MyOtherClass { } The property "org.hibernate.envers.store_data_at_delete" is set to true, and when auditquerying for the deleted objects and initiliazing the otherClass (an entity which is also deleted) property, and ObjectNotFoundExceptions is thrown. It seems that the proxies do not look for deleted entities, because the same query works fine for the entities of revision type 'ADD' and 'MOD'. The code of the query: AuditQuery queryDeleted = reader.createQuery().forRevisionsOfEntity( MyClass.class, false, true).add( AuditEntity.revisionType().eq(RevisionType.DEL)); List queryResult = queryDeleted.getResultList(); List<MyClass> result = new ArrayList<MyClass>(); for (Object object : queryResult) { Object[] oArray = (Object[]) object; MyClass c = (MyClass) oArray[0]; Hibernate.initialize(c.getOtherClass()); } Forum post with Adam Warski's response: http://community.jboss.org/thread/160939?tstart=0 -- 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

11 years, 9 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2951) Restrictions.eq when passed null, should create a NullRestriction

by David Sheldon (JIRA)

Restrictions.eq when passed null, should create a NullRestriction ----------------------------------------------------------------- Key: HHH-2951 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2951 Project: Hibernate3 Issue Type: Improvement Components: query-criteria Affects Versions: 3.2.1 Reporter: David Sheldon Priority: Trivial If you create a Restriction using eq, and pass null to it, then the generated SQL is "where foo = null", which always returns false. The programmer will almost certainly have intended to get "where foo is null". Ideally, we could change: public static SimpleExpression eq(String propertyName, Object value) { return new SimpleExpression(propertyName, value, "="); } to public static SimpleExpression eq(String propertyName, Object value) { if (value == null) { return isNull(propertyName); } else { return new SimpleExpression(propertyName, value, "="); } } Unforunately that wont work, as isNull doesn't return a SimpleExpression. -- 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

11 years, 9 months

8
13
0 / 0

[Hibernate-JIRA] Created: (HV-439) Revist the use of generics in ValidatorImpl

by Hardy Ferentschik (JIRA)

Revist the use of generics in ValidatorImpl ------------------------------------------- Key: HV-439 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-439 Project: Hibernate Validator Issue Type: Task Components: engine Affects Versions: 4.2.0.Beta1 Reporter: Hardy Ferentschik Fix For: 4.x There are several casts and {{@SupressWarning("unchecked"}} annotations in the {{ValidatorImpl}}. They should be revisited. Where the cast is safe and correct we should add a comment. In other methods (some recursive one) I am not sure how useful/correct it is to use generics. -- 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

11 years, 10 months

2
13
0 / 0

[Hibernate-JIRA] Created: (HHH-6615) int type in Revision number

by Adriano Saturno Muniz (JIRA)

int type in Revision number --------------------------- Key: HHH-6615 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6615 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.6.6 Environment: Hibernata 3.6.6, Oracle Reporter: Adriano Saturno Muniz At class DefaultRevisionEntity we have: @RevisionNumber private int id; I made a test setting the HIBERNATE_SEQUENCE to 2,147,483,647. After that, I made an audited update. The REV column of REVINFO table become negative (int type overflow) The revision number should be long, at least. No warnings / exceptions at all could be dangerous. In a overflow all the audit will stop working (envers based the version recoverry in an always increasing REV value, right?). In a very worst scenario, after a long time loosing audit, a primary key violation will happen. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3950) org.hibernate.MappingException: Type not supported for auditing: org.hibernate.type.IdentifierBagType

by David Coleman (JIRA)

org.hibernate.MappingException: Type not supported for auditing: org.hibernate.type.IdentifierBagType ----------------------------------------------------------------------------------------------------- Key: HHH-3950 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3950 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.0.GA Environment: JBoss Envers: jboss-envers-1.2.0.GA-hibernate-3.3 from org.jboss.envers (not on 3.5 of hibernate core yet) Hibernate Core: hibernate-core-3.3.0.SP1.jar JBoss + Seam Reporter: David Coleman Attachments: TypeIdentifierBagTypeNotSupportedTrace.txt Hi, I currenty have a problem with auditing a many-many relation in the entity show below. Initially I had the exact same problem as ´http://opensource.atlassian.com/projects/hibernate/browse/HHH-3843´' but on reading the documentation and releazing that the list contains duplicate elements, I add (as suggested) a @CollectionId annotation to get bag semantics. Hoewever, the seam application fails to start-up due to the error being thrown from the envers module: "type not supported for auditing: org.hibernate.type.IdentifierBagType, on entity com.baratz.absys2.core.model.api.User, property 'roles'." (stack trace attached) <snippet> @Entity @Audited @Table(name = "USER_ABSYS") public class User { @UserRoles @ManyToMany @JoinTable(name = "USER_ROLE", joinColumns = @JoinColumn(name = "UUNSEQ",unique=false) , inverseJoinColumns = @JoinColumn(name = "ROLE_ID",unique=false)) @TableGenerator(name = "UserRolesGen", table = "ABSYS_SEQUENCE", pkColumnName = "ID_NAME", valueColumnName = "NEXT_VAL", pkColumnValue = "USER_ROLE_ID_GEN", allocationSize=1) @CollectionId( columns = @Column(name="USER_ROLE_IDX"), type=@Type(type="long"), generator="UserRolesGen" ) public List<Role> getRoles() { return roles; } ... } </snippet> Regards, Dave -- 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

11 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5869) Add suport for nationalized character mappings

by Steve Ebersole (JIRA)

Add suport for nationalized character mappings ---------------------------------------------- Key: HHH-5869 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5869 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Fix For: 4.0.0.Alpha1 Since Hibernate 4 will rely on JDBC 4 (JDK 1.6) we should add support for the JDBC 4 nationalized character types: * {{Types#NCHAR}} * {{Types#NVARCHAR}} * {{Types#NCLOB} * {{Types#LONGNVARCHAR}} -- 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

11 years, 10 months

5
23
0 / 0

[Hibernate-JIRA] (HHH-7486) CascadeType.ALL is not equivalent to the combination of all other types

by Ivan Sopov (JIRA)

11 years, 10 months

2
4
0 / 0

[Hibernate-JIRA] Created: (ANN-819) @Any mapping fails during configuration: "@Any requires an explicit @JoinColumn(s)"

by Noah Miller (JIRA)

@Any mapping fails during configuration: "@Any requires an explicit @JoinColumn(s)" ----------------------------------------------------------------------------------- Key: ANN-819 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-819 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.4.0.GA, 3.4.0.CR2, 3.4.0.CR1, 3.3.1.GA Environment: Hibernate core 3.2.4.sp1 (reported in 3.3.1.GA as well) Hibernate annotations 3.3.1.GA (reported in 3.4.0.GA as well) Hibernate entity manager 3.3.1.ga MySQL 5.0.45 Reporter: Noah Miller When I try to apply the @Any annotation, I get the following exception: ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=persistence.units:jar=test-build.jar,unitName=blueserve state=Create org.hibernate.AnnotationException: @Any requires an explicit @JoinColumn(s): com.builderadius.blueserve.model.Note.noteOwner at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1201) at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:739) at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:501) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:282) at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115) at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1195) at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:149) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:814) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:412) at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:126) at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:259) See the forum posting http://forum.hibernate.org/viewtopic.php?p=2403045 for another description of this problem. That thread suggests the problem is with EJB3OverridenAnnotationReader not adding properties annotated with @JoinColumn if xml mapping files exist. My code is: @Any(metaColumn = @Column(name = "RelatedRecType")) @AnyMetaDef(idType = "integer", metaType = "string", metaValues = { @MetaValue(targetEntity = Approval.class, value = "approval"), @MetaValue(targetEntity = ZoningPermit.class, value = "zoningpermit") }) @JoinColumn(name = "RelatedRecNum", nullable = false) public BlueserveEntity getNoteOwner() { return this.noteOwner; } An orm.xml file (auto-generated by seam-gen) exists in this project, though it has no entity mappings and there are no other hbm.xml files. When I remove this file, I no longer receive the exception (that's not a long-term solution). -- 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

11 years, 10 months

5
5
0 / 0

[Hibernate-JIRA] Created: (BVTCK-11) Wrong usage of context classloader to discover resources in META-INF/services

by Hardy Ferentschik (JIRA)

Wrong usage of context classloader to discover resources in META-INF/services ----------------------------------------------------------------------------- Key: BVTCK-11 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11 Project: Bean Validation TCK Issue Type: Bug Components: TCK Appeal Affects Versions: 1.0.4.GA Reporter: Hardy Ferentschik Assignee: Emmanuel Bernard *Problem Description*: The test uses the context classloader to discover all META-INF/services/javax.validation.spi.ValidationProvider resources and checks whether one of the resource files contains the ValidationProvider currently under the test. This method of checking for ValidationProvider might not work on all containers. Especially on containers with constrained classloaders (e.g. OSGi). The Bean Validation specification in section 4.4.4.1 talks about this exact problem. That's why the test should be using ValidationProviderResolver API to check for right provider instead of looking for the resource files. *Tests affected*: org.hibernate.jsr303.tck.tests.bootstrap.ValidationProviderResolverTest#testServiceFileExists() -- 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

11 years, 10 months

5
22
0 / 0

[Hibernate-JIRA] Created: (HHH-3238) impossible to get the rowcount for a criteria that has projections

by hbMailingList (JIRA)

impossible to get the rowcount for a criteria that has projections ------------------------------------------------------------------ Key: HHH-3238 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3238 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6 Environment: hibernate 3.2.6, oracle 10g Reporter: hbMailingList Projections.rowCount correctly returns the NUMBER_OF_ROWS for the criteria's resultset. However if the criteria already has a projection then rowcount no longer returns the NUMBER_OF_ROWS in the result set. For example: Criteria c=session.CreateCriteria(Cat.class); ProjectionList pl = ...; .... pl.add(Projections.groupProperty("color")); pl.add(Projections.rowCount()); c.setProjections(pl); c.list(); will result in the following query: select color, count(*) from cats group by color I would expect it to result in: select count(*) from (select color from cats group by color) after all if I wanted the count by color I could have simply done: Projections.count(...) I really need this feature for my project...if you don't think this will make the release, would you please give me a hint and I'll submit a patch. Thanks for all the hard work. -- 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

11 years, 10 months

5
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2012