June 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3332) Hibernate duplicate then child entity's on merge

by Rodrigo de Assumpção (JIRA)

Hibernate duplicate then child entity's on merge ------------------------------------------------ Key: HHH-3332 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3332 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6 Environment: JDK 1.6 Oracle 9i Hibernate 3.2.6 Hibernate Annotations 3.3.1 Hibernate EntityManager 3.3.2 Standalone Running Reporter: Rodrigo de Assumpção Priority: Critical The method merge from EntityManager causes a duplication of child entity's. class Father: @OneToMany(mappedBy = "father", cascade={CascadeType.ALL}, fetch=FetchType.LAZY) private List<Child> childList; class Child: @ManyToOne @JoinColumn(name = "ID_FATHER") private Father father; class BugTest EntityManagerFactory emf = Persistence.createEntityManagerFactory("JpaTestHB"); EntityManager em = emf.createEntityManager(); Father f = (Father) em.createQuery("SELECT f FROM Father f WHERE f.id = 1").getSingleResult(); Child c = new Child(); c.setFather(f); f.getChildList().add(c); em.getTransaction().begin(); em.merge(f); em.getTransaction().commit(); The execution of BugTest Class causes tow insert's on table "child". If you change the fetch mode to EAGER (into Father class) the problem not occurs. I make the same test with Toplink, and it make a unique insert, normal. -- 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

13
29
0 / 0

[Hibernate-JIRA] Created: (ANN-747) @CollectionOfElements does not cascade on delete

by Nicole Rauch (JIRA)

@CollectionOfElements does not cascade on delete ------------------------------------------------ Key: ANN-747 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-747 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Environment: Hibernate 3.2.6 GA Database: H2 1.0.72 Reporter: Nicole Rauch Consider the following constellation: @Embeddable public class Foo { // ... } @Entity public class Bar { @CollectionOfElements private Set<Foo> myFoos; // ... } When I persist a Bar object that contains some Foos, and when I later decide to delete the Bar object, I get a foreign key constraint violation error message because the Foo objects, which contain a reference to the Bar object that owns them, are not deleted automatically. I would expect the default behaviour to be "on delete cascade" because the Foo objects are embeddables, thus they cannot exist on their own without the Bar object that owns them. But there is no way to tell Hibernate to cascade: - the @OnDelete annotation is only allowed for OneToMany relations - the @Cascade annotation is being ignored - there is no "cascade" property for the CollectionOfElements So my question is: Why does the cascading not occur automatically, and how do I tell Hibernate to cascade anyways? Thanks a lot in advance, Nicole -- 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, 3 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3273) One-to-Many relationship not working with custom Loader

by Darren Hicks (JIRA)

One-to-Many relationship not working with custom Loader -------------------------------------------------------- Key: HHH-3273 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3273 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1 Environment: hibernate-3.2.6.jar Reporter: Darren Hicks Within the context of a One-to-Many relationship, NamedQueryCollectionInitializer .initialize() never actually populates the PersistantBag on the parent after it calls query.setCollectionKey( key ).setFlushMode( FlushMode.MANUAL ).list() to retrieve the children. This is documented in the forums here: http://forums.hibernate.org/viewtopic.php?t=986428 Additionally, the poster has a fix posted which may solve the problem, or at least lay out the groundwork for a solution. Here is the proposed implementation of NamedQueryCollectionInitializer.initialize(): public void initialize(Serializable key, SessionImplementor session) throws HibernateException { if (log.isDebugEnabled()) { log.debug("initializing collection: " + persister.getRole() + " using named query: " + queryName); } // TODO: is there a more elegant way than downcasting? AbstractQueryImpl query = (AbstractQueryImpl) session .getNamedSQLQuery(queryName); if (query.getNamedParameters().length > 0) { query.setParameter(query.getNamedParameters()[0], key, persister .getKeyType()); } else { query.setParameter(0, key, persister.getKeyType()); } List list = query.setCollectionKey(key).setFlushMode(FlushMode.MANUAL) .list(); // Uh, how 'bout we save the collection for later retrieval? CollectionKey collectionKey = new CollectionKey(persister, key, session .getEntityMode()); for (Object object : session.getPersistenceContext() .getCollectionsByKey().keySet()) { if (collectionKey.equals(object)) { PersistentCollection persistentCollection = session .getPersistenceContext().getCollection(collectionKey); Serializable[] serializables = new Serializable[list.size()]; for (int i = 0; i < list.size(); i++) { serializables[i] = persister.getElementType().disassemble( list.get(i), session, persistentCollection.getOwner()); } persistentCollection.initializeFromCache(persister, serializables, persistentCollection.getOwner()); persistentCollection.setSnapshot(key, persistentCollection .getRole(), serializables); persistentCollection.afterInitialize(); session.getPersistenceContext().getCollectionEntry( persistentCollection).postInitialize( persistentCollection); } } } -- 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, 3 months

6
9
0 / 0

[Hibernate-JIRA] Created: (EJB-328) Missing flush before lock() when LockModeType is AUTO

by Per Olesen (JIRA)

Missing flush before lock() when LockModeType is AUTO ----------------------------------------------------- Key: EJB-328 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-328 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Affects Versions: 3.3.1.GA Environment: core: 3.2.5.ga entitymanager: 3.3.1.ga annotations: 3.3.0.ga Reporter: Per Olesen Priority: Minor When I try to WRITE lock() a newly persisted entity using entityManager.lock, I get a StaleObjectStateException, telling me that some other transaction updated or deleted the row. I am doing this in the same transaction (persist and lock). By digging into the code, I see that the exception is thrown inside the SelectLockingStrategy.lock method, around these lines: ResultSet rs = st.executeQuery(); try { if ( !rs.next() ) { if ( factory.getStatistics().isStatisticsEnabled() ) { factory.getStatisticsImplementor() .optimisticFailure( lockable.getEntityName() ); } throw new StaleObjectStateException( lockable.getEntityName(), id ); } } The query executed here is the one which performs the select on id with FOR UPDATE. This select finds nothing, hence the exception. Setting show_sql = true shows me, that no insert is performed. Debugging the flush mode tells me, that it is set to AUTO. Shouldn't AUTO flush mode have the side effect, that a flush is performed before a query? Performing an explicit flush, before the lock, makes everything green :-), so this is my current work-around. Here is the exception (sanitized for company info): org.springframework.orm.jpa.JpaOptimisticLockingFailureException: nested exception is javax.persistence.OptimisticLockException Caused by: javax.persistence.OptimisticLockException at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:643) at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:600) at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:379) ... Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.foo.bar#32] at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:78) at org.hibernate.persister.entity.AbstractEntityPersister.lock(AbstractEntityPersister.java:1334) at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:88) at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64) at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584) at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576) at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:376) ... -- 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, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3007) Unchanged persistent set gets marked dirty on session.merge()

by Lars Koedderitzsch (JIRA)

Unchanged persistent set gets marked dirty on session.merge() ------------------------------------------------------------- Key: HHH-3007 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3007 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: Lars Koedderitzsch Persistent sets are marked dirty on session.merge() even if there have been no changes to the collection. This is especially painful when the collection is immutable and results in an "changed an immutable collection instance" exception on flush. I tracked the behaviour down a bit and believe the problem to be in CollectionType.replace(). Here the passed in orginal PersistentSet is replaced by a plain HashSet in this line: Object result = target == null || target == original ? instantiateResult( original ) : target; The "result" object (HashSet) is then passed to the CollectionType.replaceElements() method (instead of the original PersistentSet). In CollectionType.replaceElements() the code to clear the dirty state of the collection does not execute anymore, because the passed-in "original" collection is the described HashSet and *not* the original PersistentSet. This way the PersistentSet remains marked dirty. A workaround is to manually clear the dirty state of an immutable collection after merge but before flush. -- 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, 4 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2716) Session.replicate failure with identity column

by Yves Martin (JIRA)

Session.replicate failure with identity column ---------------------------------------------- Key: HHH-2716 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2716 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.2 Environment: Java 1.5, MySQL 5.0.27 and Hibernate Annotations 3.2.1.GA Reporter: Yves Martin I'm trying to use replicate: http://www.hibernate.org/hib_docs/reference/en/html/objectstate.html#obje... The column "@version" is replicated properly (same value in second db) but the column "@Id @GeneratedValue" contains a new value from the db2 sequence. In fact the insert statement generated by the replicate method does not include the "id" column. -- 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, 4 months

6
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3081) SQL queries do not currently support iteration

by MG (JIRA)

SQL queries do not currently support iteration ---------------------------------------------- Key: HHH-3081 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3081 Project: Hibernate3 Issue Type: Bug Reporter: MG Query sqlQuery = session.createSQLQuery("select * from TRADE").addEntity(Trade.class); sqlQuery.setReadOnly(true); sqlQuery.setCacheMode(CacheMode.IGNORE); sqlQuery.setCacheable(false); sqlQuery.setFetchSize(1000); Iterator<Trade> trades = sqlQuery.iterate(); Causes Exception in thread "main" java.lang.UnsupportedOperationException: SQL queries do not currently support iteration at org.hibernate.impl.SQLQueryImpl.iterate(SQLQueryImpl.java:190) -- 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, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2315) relax schemaupdate complaining about numeric/decimal

by Max Rydahl Andersen (JIRA)

relax schemaupdate complaining about numeric/decimal ---------------------------------------------------- Key: HHH-2315 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2315 Project: Hibernate3 Type: Improvement Components: core Reporter: Max Rydahl Andersen Fix For: 3.2.2 http://jira.jboss.com/jira/browse/JBSEAM-596 -- 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, 4 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3356) Support for subselect (subquery) in from clause

by Geoffrey De Smet (JIRA)

Support for subselect (subquery) in from clause ----------------------------------------------- Key: HHH-3356 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3356 Project: Hibernate3 Issue Type: New Feature Components: query-hql Reporter: Geoffrey De Smet Many databases support subselects in the from clause, for example: http://dev.mysql.com/doc/refman/5.0/en/unnamed-views.html And it's very handy. Native query's are sometimes a working workaround, but have many disadvantages, unlike HQL. Btw, I've searched through jira for over 20 minutes and didn't find an issue for this already. If there is one already, please give it a better title or link it to this issue :) -- 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, 4 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2097) LAZY property results in org.hibernate.TransientObjectException after merge

by Reto Urfer (JIRA)

LAZY property results in org.hibernate.TransientObjectException after merge --------------------------------------------------------------------------- Key: HHH-2097 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2097 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr4 Environment: Hibernate3.2 cr4 with Annotations cr2 and EntityManager cr2, Oracle10g R2, WindowsXP Reporter: Reto Urfer Priority: Critical Attachments: BugLazyPropertyMerge.zip Entity1 has a property e2 which references Entity2. This property is defined as follows. @ManyToOne(fetch = FetchType.LAZY, optional = false) private Entity2 e2; If you have an instance e1 of Entity1 which has not initialized property e2 and you merge e1 to the EntityManager within a transaction, then you get the following exception during commit: Exception in thread "main" javax.persistence.RollbackException: Error while commiting the transaction at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:63) at com.test.Test.main(Test.java:42) Caused by: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.test.Entity1.e2 -> com.test.Entity2 at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:350) at org.hibernate.engine.Cascade.cascade(Cascade.java:139) at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:130) at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:121) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:53) ... 1 more I added a small Testproject to reproduce this bug. -- 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, 4 months

4
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2008