October 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5534) Regression in 3.5.5: Cascade on merge for Sets fails with transient entities

by Kyrill Alyoshin (JIRA)

Regression in 3.5.5: Cascade on merge for Sets fails with transient entities ----------------------------------------------------------------------------- Key: HHH-5534 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5534 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.5 Environment: Hibernate 3.5.5, Oracle 10g. Reporter: Kyrill Alyoshin Something happened from 3.5.4 to 3.5.5. Here is regression issue we're experiencing after upgrade: We have entities ResearchClientFile and ResearchVendorRecord. RCF maps RVR: @Sort(type = SortType.NATURAL) @OneToMany(mappedBy = "file", fetch = FetchType.LAZY, cascade = CascadeType.ALL) public SortedSet<ResearchVendorRecord> getRecords() { return records; } RVR maps RCF: @ManyToOne(fetch = FetchType.LAZY, optional = false) @JoinColumn(name = "research_client_file_id") public ResearchClientFile getFile() { return file; } The following unit test: ResearchClientFile rcf = RandomUtils.randomBean(ResearchClientFile.class); rcf.addRecord(RandomUtils.randomBean(ResearchVendorRecord.class)); rcf = session.merge(rcf); produces the following exception in 3.5.5 but not in 3.5.4.: java.lang.NullPointerException: null entities are not supported by org.hibernate.event.def.EventCache at org.hibernate.event.def.EventCache.containsKey(EventCache.java:80) at org.hibernate.event.def.DefaultMergeEventListener.mergeTransientEntity(DefaultMergeEventListener.java:361) at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:303) at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:258) at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:869) equals, hashCode and compareTo are completely consistent in RVR. The issue seems to affects only Set and SortedSets and on merge only. Lists (with bag semantics) do not appear to be affected on merge. Of all the things touch in 3.5.5 (according to the changelog) this issue seems to be the only one dealing with merge functionality, so I decided to put a comment here. I will also create a bug that described this in detail. -- 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

13 years, 8 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-4074) Polymorphic queries avoid with polymorphism="explicit" in hbm.xml file doesn't work

by Radics Laszlo (JIRA)

Polymorphic queries avoid with polymorphism="explicit" in hbm.xml file doesn't work ----------------------------------------------------------------------------------- Key: HHH-4074 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4074 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: hibernate 3.3.2 Oracle 9i Reporter: Radics Laszlo hbm.xml: <hibernate-mapping default-cascade="none"> <class name="hu.raiffeisen.aps.soa.entity.collateral.AncestorImpl" table="ANCESTOR" dynamic-insert="false" dynamic-update="false" polymorphism="explicit"> <id name="id" type="java.lang.Long" unsaved-value="null"> <column name="ID" sql-type="NUMBER(19)"/> <generator class="sequence"> <param name="sequence">ANCESTOR_SEQ</param> </generator> </id> <property name="top" type="java.lang.Long"> <column name="TOP" not-null="true" unique="false" sql-type="NUMBER(19)"/> </property> <union-subclass name="hu.raiffeisen.aps.soa.entity.collateral.DescendantImpl" table="DESCENDANT" dynamic-insert="false" dynamic-update="false" abstract="false"> <property name="bottom" type="java.lang.Long"> <column name="BOTTOM" not-null="true" unique="false" sql-type="NUMBER(19)"/> </property> </union-subclass> </class> </hibernate-mapping> hql: "from AncestorImpl" fetch both ancestor and descendant rows -- 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

13 years, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-352) DefaultTraversableResolver and ValidationXmlParser throw ValidationException without passing on the original Exception

by Hardy Ferentschik (JIRA)

DefaultTraversableResolver and ValidationXmlParser throw ValidationException without passing on the original Exception ---------------------------------------------------------------------------------------------------------------------- Key: HV-352 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-352 Project: Hibernate Validator Issue Type: Bug Components: engine Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0 The original exception should not be swallowed -- 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

13 years, 8 months

1
2
0 / 0

[Hibernate-JIRA] Created: (ANN-470) enrich UniqueConstraint with property name

by Johnny D. (JIRA)

enrich UniqueConstraint with property name ------------------------------------------ Key: ANN-470 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-470 Project: Hibernate Annotations Type: Improvement Reporter: Johnny D. To be able in annotation to give uniqueConstraint exact database name, there is need to add field java.lang.String name(); to annotation class UniqueConstraint in similar way like in index is. -- 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

13 years, 8 months

5
10
0 / 0

[Hibernate-JIRA] Created: (HV-348) Add note to JPA integration section about access type when using lazy loaded OneToOne and ManyToOne associations

by Hardy Ferentschik (JIRA)

Add note to JPA integration section about access type when using lazy loaded OneToOne and ManyToOne associations ---------------------------------------------------------------------------------------------------------------- Key: HV-348 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-348 Project: Hibernate Validator Issue Type: Task Components: documentation Affects Versions: 4.1.0.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0 https://forum.hibernate.org/viewtopic.php?f=9&t=1005515 -- 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

13 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4042) StatelessSession does not flush when using jdbc batch_size > 1

by Gael Beaudoin (JIRA)

StatelessSession does not flush when using jdbc batch_size > 1 -------------------------------------------------------------- Key: HHH-4042 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4042 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: JBoss 4.2.3, Linux, java 1.6, hibernate 3.3.1, entityManager 3.4.0, jboss seam 2.1.2, postgresql 8.3 Reporter: Gael Beaudoin I'm using a StetelessSession to insert millions of rows : it works great and without using much memory. But I've just seen that with a jdbc batch size of 50 for example (<property name="hibernate.jdbc.batch_size" value="0"/> in my persistence.xml) the last round of inserts aren't flushed to the database. For example, with 70 insert, only the first 50 are sent to the database. I've searched a lot about this issues and on this thread (https://forum.hibernate.org/viewtopic.php?f=1&t=987882&start=0), the only solution found is to set the batch_size to 1, which is really a shame. I've tried to flush the session, close the jdbc connection, etc etc ... no luck. I'd be fine with a way to set the batch_size to 1 only for this method, pro grammatically, but I've not found any way to do that. If you don't pay attention, it's a easy way to lose data. -- 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

13 years, 8 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HV-327) Update TCK runner dependecies to not depend on the JBoss deprecated repo

by Hardy Ferentschik (JIRA)

Update TCK runner dependecies to not depend on the JBoss deprecated repo ------------------------------------------------------------------------ Key: HV-327 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-327 Project: Hibernate Validator Issue Type: Task Components: build, tck Affects Versions: 4.1.0.Beta1 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0 The current build for the tck runner module depends (transitively) on dependencies from the JBoss deprecated repository - https://repository.jboss.org/nexus/content/repositories/deprecated/ We should try if possible to avoid the usage of this repository. Not sure how far this is possible since it would require that there are properly configured upstream dependencies. -- 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

13 years, 8 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5677) Problem with ManyToOne to a unique key on merge when old value is null

by Marcial Atienzar (JIRA)

Problem with ManyToOne to a unique key on merge when old value is null ---------------------------------------------------------------------- Key: HHH-5677 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5677 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.6.0 Reporter: Marcial Atienzar *Entity 1*: {code} @ManyToOne(fetch=FetchType.LAZY,cascade=CascadeType.REFRESH) @JoinColumn(name = "UPC", referencedColumnName = "CLAVE_PRO",unique=false,insertable=false,updatable=false) private RhDatosPersonales upcRrhh; {code} *Entity 2*: {code} @Id @Column(name = "NUM", nullable = false) private BigDecimal num; @Column(name = "CLAVE_PRO",unique=true,insertable=false,updatable=false,nullable=true) private Long clavePro; {code} *Exception* {code} Caused by: java.lang.ClassCastException: org.kyrian.entity.rrhh.RhDatosPersonales cannot be cast to java.math.BigDecimal at org.hibernate.type.descriptor.java.BigDecimalTypeDescriptor.areEqual(BigDecimalTypeDescriptor.java:36) at org.hibernate.type.AbstractStandardBasicType.isEqual(AbstractStandardBasicType.java:183) at org.hibernate.type.AbstractStandardBasicType.isSame(AbstractStandardBasicType.java:168) at org.hibernate.type.AbstractStandardBasicType.isDirty(AbstractStandardBasicType.java:213) at org.hibernate.type.AbstractStandardBasicType.isDirty(AbstractStandardBasicType.java:205) at org.hibernate.type.ManyToOneType.isDirty(ManyToOneType.java:268) at org.hibernate.type.ManyToOneType.isDirty(ManyToOneType.java:277) at org.hibernate.type.TypeHelper.findDirty(TypeHelper.java:296) at org.hibernate.persister.entity.AbstractEntityPersister.findDirty(AbstractEntityPersister.java:3378) at org.hibernate.event.def.DefaultFlushEntityEventListener.dirtyCheck(DefaultFlushEntityEventListener.java:520) at org.hibernate.event.def.DefaultFlushEntityEventListener.isUpdateNecessary(DefaultFlushEntityEventListener.java:230) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:154) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383) at org.hibernate.transaction.synchronization.CallbackCoordinator.beforeCompletion(CallbackCoordinator.java:117) {code} -- 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

13 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-391) Review assertions of @Past and @Future tests

by Kevin Pollet (JIRA)

Review assertions of @Past and @Future tests -------------------------------------------- Key: HV-391 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-391 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.2.0 Reporter: Kevin Pollet Assignee: Kevin Pollet Priority: Blocker Fix For: 4.2.0 Some @Past and @Future tests can fail because of current time -- 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

13 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-363) HV uses Thread's context class loader to load internal implementation classes

by Sanjeeb Sahoo (JIRA)

HV uses Thread's context class loader to load internal implementation classes ----------------------------------------------------------------------------- Key: HV-363 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-363 Project: Hibernate Validator Issue Type: Bug Components: engine Reporter: Sanjeeb Sahoo Assignee: Hardy Ferentschik Priority: Blocker org.hibernate.validator.engine.resolver.DefaultTraversableResolver uses Thread's context class loader to load JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME, which is org.hibernate.validator.engine.resolver.JPATraversableResolver. Why? Since one implementation class is looking for another implementation class, should it not use getClass().getClassLoader() instead? The relevant code is given below: private void detectJPA() { try { loadClass( PERSISTENCE_UTIL_CLASS_NAME, this.getClass() ); log.debug( "Found {} on classpath.", PERSISTENCE_UTIL_CLASS_NAME ); } catch ( ValidationException e ) { log.debug( "Cannot find {} on classpath. All properties will per default be traversable.", PERSISTENCE_UTIL_CLASS_NAME ); return; } try { @SuppressWarnings( "unchecked" ) Class<? extends TraversableResolver> jpaAwareResolverClass = (Class<? extends TraversableResolver>) loadClass(JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME, this.getClass() ); NewInstance<? extends TraversableResolver> newInstance = NewInstance.action( jpaAwareResolverClass, "" ); if ( System.getSecurityManager() != null ) { jpaTraversableResolver = AccessController.doPrivileged( newInstance ); } else { jpaTraversableResolver = newInstance.run(); } log.info( "Instantiated an instance of {}.", JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME ); } catch ( ValidationException e ) { log.info( "Unable to load or instanciate JPA aware resolver {}. All properties will per default be traversable.", JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME ); } } -- 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

13 years, 8 months

5
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2010