March 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-1917) Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1917?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-1917: ------------------------------------- Perhaps, although they never show exactly what their {{deleteAll}} method does. Assuming it tries to perform a bulk delete, then it would seem to be the same situation. > Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable > ------------------------------------------------------------------------------------------------------------- > > Key: HHH-1917 > URL: https://hibernate.onjira.com/browse/HHH-1917 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.2.0.cr2 > Environment: Hibernate 3.2 cr2 > Hibernate Annotations 3.2.0.CR1 > Hibernate Entity Manager 3.2.0.CR1 > Oracle 10.1, with Oracle 10.2 JDBC Driver > Reporter: Keenan Ross > > Emmanuel says in http://forum.hibernate.org/viewtopic.php?t=961140, > [quote]I also know we need to fix some limitations regarding associations table updates / delete and bulk operations[/quote] > This issue provides a reminder that this task is pending. > For bulk deletes, consider this scenario: Assume Person and Group entities in a bidirectional ManyToMany relationship with Group as the owning side. This implies a Join table, with the default name of Group_Person. Currently issuing > em.createQuery("delete from Group").executeUpdate(); > makes no attempt to delete the corresponding rows from Group_Person, even though Group is the owning side, giving constraint errors. Since Group_Person has no corresponding entity, I don't think the spec's prohibition on lifecycle operations or cascading applies here. The only workarround is to individually delete the Groups. > --keenan -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1917) Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1917?page=com.atlassian.jira.plug... ] Steve Ebersole updated HHH-1917: -------------------------------- Issue Type: Improvement (was: Bug) This works as designed and therefore cannot be a bug. You are asking for an improvement. > Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable > ------------------------------------------------------------------------------------------------------------- > > Key: HHH-1917 > URL: https://hibernate.onjira.com/browse/HHH-1917 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.2.0.cr2 > Environment: Hibernate 3.2 cr2 > Hibernate Annotations 3.2.0.CR1 > Hibernate Entity Manager 3.2.0.CR1 > Oracle 10.1, with Oracle 10.2 JDBC Driver > Reporter: Keenan Ross > > Emmanuel says in http://forum.hibernate.org/viewtopic.php?t=961140, > [quote]I also know we need to fix some limitations regarding associations table updates / delete and bulk operations[/quote] > This issue provides a reminder that this task is pending. > For bulk deletes, consider this scenario: Assume Person and Group entities in a bidirectional ManyToMany relationship with Group as the owning side. This implies a Join table, with the default name of Group_Person. Currently issuing > em.createQuery("delete from Group").executeUpdate(); > makes no attempt to delete the corresponding rows from Group_Person, even though Group is the owning side, giving constraint errors. Since Group_Person has no corresponding entity, I don't think the spec's prohibition on lifecycle operations or cascading applies here. The only workarround is to individually delete the Groups. > --keenan -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7137) I would like to have issue HHH-6607 reopenned

by Rich Christy (JIRA)

I would like to have issue HHH-6607 reopenned --------------------------------------------- Key: HHH-7137 URL: https://hibernate.onjira.com/browse/HHH-7137 Project: Hibernate ORM Issue Type: Bug Components: envers Affects Versions: 3.6.7 Reporter: Rich Christy Priority: Critical See issue HHH-6607 http://opensource.atlassian.com/projects/hibernate/browse/HHH-6607 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6607) Exceptions being hidden in JDBCTransation

by Rich Christy (JIRA)

Exceptions being hidden in JDBCTransation ----------------------------------------- Key: HHH-6607 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6607 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.6.7 Environment: The issue happens when the audit schema is different from the primary schema say because of a column change. The database session is rolled back but the exception isn't thrown up to any levels past the notifyLocalSynchsBeforeTransactionCompletion() so any applications needing to recover from database failures cannot - say rolling back application caches. The way to reproduce this is to drop a column in the aud table for any domain object and try to insert the data Reporter: Rich Christy 2011-08-24 16:00:15,886 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session org.hibernate.exception.SQLGrammarException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:114) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:109) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:244) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2242) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2678) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028) at org.hibernate.envers.synchronization.AuditSync.beforeCompletion(AuditSync.java:161) at org.hibernate.transaction.JDBCTransaction.notifyLocalSynchsBeforeTransactionCompletion(JDBCTransaction.java:274) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:140) at org.openspaces.persistency.hibernate.DefaultHibernateExternalDataSource.executeBulk(DefaultHibernateExternalDataSource.java:107) at com.skyroad.motion.transactionmanager.util.TransactionMirrorExternalDataSource.executeBulk(TransactionMirrorExternalDataSource.java:32) What the code is doing in the exception handling of AuditSync.java (5th line from the bottom in the stack track) is rolling back the transaction as far as the hibernate session is concerned and then unconditionally throwing the exception to the next level. However, the code in notifyLocalSynchsBeforeTransactionCompletion() eating the exception so Gigaspaces isn't aware that it happened. This would explain why the database writes are rolled back but the space isn't. public void beforeCompletion() { if (workUnits.size() == 0 && undoQueue.size() == 0) { return; } try { // see: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178431 if (FlushMode.isManualFlushMode(session.getFlushMode()) || session.isClosed()) { Session temporarySession = null; try { temporarySession = session.getFactory().openTemporarySession(); executeInSession(temporarySession); temporarySession.flush(); } finally { if (temporarySession != null) { temporarySession.close(); } } } else { executeInSession(session); // Explicity flushing the session, as the auto-flush may have already happened. session.flush(); } } catch (RuntimeException e) { // Rolling back the transaction in case of any exceptions //noinspection finally try { if (session.getTransaction().isActive()) { session.getTransaction().rollback(); } } finally { //noinspection ThrowFromFinallyBlock throw e; } } } private void notifyLocalSynchsBeforeTransactionCompletion() { if (synchronizations!=null) { for ( int i=0; i<synchronizations.size(); i++ ) { Synchronization sync = (Synchronization) synchronizations.get(i); try { sync.beforeCompletion(); } catch (Throwable t) { log.error("exception calling user Synchronization", t); } } } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7096) Settings not available in SingletonEhCacheRegionFactory

by Eric Dalquist (JIRA)

Settings not available in SingletonEhCacheRegionFactory ------------------------------------------------------- Key: HHH-7096 URL: https://hibernate.onjira.com/browse/HHH-7096 Project: Hibernate ORM Issue Type: Bug Affects Versions: 4.1.0, 4.0.1 Reporter: Eric Dalquist SingletonEhCacheRegionFactory does not populate the Settings field which can cause failures when creating cache regions -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-7097) Entity load event doesn't result in naturalId->pk caching

by Eric Dalquist (JIRA)

Entity load event doesn't result in naturalId->pk caching --------------------------------------------------------- Key: HHH-7097 URL: https://hibernate.onjira.com/browse/HHH-7097 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.0 Reporter: Eric Dalquist When an entity is loaded the naturalId->pk session and 2L caches for that entity should be populated -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-238) Support for container injection in ConstraintValidator

by Gerhard Petracek (JIRA)

Support for container injection in ConstraintValidator ------------------------------------------------------ Key: BVAL-238 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-238 Project: Bean Validation Issue Type: New Feature Components: spec-general Affects Versions: 1.0 final Reporter: Gerhard Petracek It should be possible to inject beans in implementations of javax.validation.ConstraintValidator. E.g. MyFaces CODI supports it already for CDI (https://issues.apache.org/jira/browse/EXTCDI-20), however as mentioned in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-763 a generic support would have to support JSR-330 (instead of JSR-299). The final approach has to be coordinated with all other JSRs which are going to provide such an injection support. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-228) Prepare specification document and Git repository for public eyes

by Emmanuel Bernard (JIRA)

Prepare specification document and Git repository for public eyes ----------------------------------------------------------------- Key: BVAL-228 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-228 Project: Bean Validation Issue Type: Task Components: spec-general Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 1.1 -- 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

12 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (BVAL-194) Invalid license info

by Stevo Slavic (JIRA)

Invalid license info -------------------- Key: BVAL-194 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-194 Project: Bean Validation Issue Type: Bug Affects Versions: 1.0 final Reporter: Stevo Slavic Priority: Minor validation-api-1.0.0.GA.pom declares Apache 2 as license but with invalid URL and license name is not standard. Please adjust license info in the pom to be as in [apache parent pom|http://repo1.maven.org/maven2/org/apache/apache/6/apache-6.pom] as this will improve how dependency to this project artifact is treated by all sorts of maven plug-ins and tools, like project info dependency report plugin, maven jboss license plugin, etc. So instead: {code} <licenses> <license> <name>Apache License, Version 2.0</name> <url>license.txt</url> </license> </licenses> {code} should be: {code} <licenses> <license> <name>The Apache Software License, Version 2.0</name> <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> <distribution>repo</distribution> </license> </licenses> {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

12 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-265) Expose settings defined in XML in the Configuration API (for ConstraintValidatorFactory, MessageInterpolator etc)

by Emmanuel Bernard (JIRA)

Expose settings defined in XML in the Configuration API (for ConstraintValidatorFactory, MessageInterpolator etc) ----------------------------------------------------------------------------------------------------------------- Key: BVAL-265 URL: https://hibernate.onjira.com/browse/BVAL-265 Project: Bean Validation Issue Type: New Feature Components: spec-general Reporter: Emmanuel Bernard -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2012