[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2792?page=c... ] Chris Rose commented on HHH-2792: --------------------------------- I'd like to clarify this; this is an issue I'm having, too; I call delete on an entity with its id field filled in, but the nullability of _all_ of its fields is validated as an _update_ prior to deletion. The code in question is in DefaultDeleteEventListener.deleteEntity( final EventSource session, final Object entity, final EntityEntry entityEntry, final boolean isCascadeDeleteEnabled, final EntityPersister persister, final Set transientEntities) on line 250: new Nullability( session ).checkNullability( entityEntry.getDeletedState(), persister, true ); This checks the entity as if it were an update, which causes a PropertyValueException in the case that the key itself is provided, but no other properties are filled in, which should not be necessary for a delete operation. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2792?page=c... ] Carl Allain commented on HHH-2792: ---------------------------------- I have the same question than you. Why do Hibernate end up 1) setting properties referencing deleted instances to null on a deleted entity 2) checking for nullability stuff (as 1) just broke everything) 3) if I put optional=true all over the place in my annotations, HB would pass 1) and 2) but fail with an attempted updated with null values on the deleted entities (deleted through cascading) There is some weird code that seems to handle this kind of situation (updating a deleted entity), but the only difference is in logging! <code> DefaultFlushEntityEventListener: ... private boolean scheduleUpdate(final FlushEntityEvent event) { final EntityEntry entry = event.getEntityEntry(); final EventSource session = event.getSession(); final Object entity = event.getEntity(); final Status status = entry.getStatus(); final EntityMode entityMode = session.getEntityMode(); final EntityPersister persister = entry.getPersister(); final Object[] values = event.getPropertyValues(); if ( log.isTraceEnabled() ) { if ( status == Status.DELETED ) { log.trace( "Updating deleted entity: " + MessageHelper.infoString( persister, entry.getId(), session.getFactory() ) ); } else { log.trace( "Updating entity: " + MessageHelper.infoString( persister, entry.getId(), session.getFactory() ) ); } } </code> I don't understand why these things are done this way and it does not seem there is a good documentated explanation for it (forum, book, PDF, etc.). -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2792?page=c... ] Ryan Stewart commented on HHH-2792: ----------------------------------- This is still an issue in 3.3.1. It makes test-writing somewhere between difficult and nearly impossible. To get around it for now, instead of: session.delete(foo); you can use: Query q = session.createQuery("delete from " + foo.getClass().getSimpleName() + " where id = ?"); q.setParameter(0, foo.getId()); q.executeUpdate(); This is very annoying! -- 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