[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
13 years, 4 months
[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
13 years, 5 months
[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
13 years, 5 months