Hi all.

When I delete an object from database, I have to make other actions over the database. usually, I encapsulate these actions in a transactional delete method, where I call Hibernate API delete method.

I mean:

void deleteObject(Object o) {
openTransaction();
makeActions(); //these actions affect the database
delete(o);
closetransaction();
}

The problem is when an object o is deleted in cascade, so it doesn't invoke my deleteobject() method.

I want to embed makeActions() in a PreDeleteEvent.

Event is listened right, but when executing makeActions(), it doesn't work.
Can't I work with database in a Hibernate Eventlistener?

there might be a better way to do this through hibernate's api.

But why not just make every object call the child's objects deleteObject. before you delete the object?

If I have to call the delete method for each child level, why exists a cascade mechanism?

Actually, the problem is a little bit more complex: I have specified CascadeOrphan, because I need to be able to remove an object from a collection (set) in a parent object, and to persist that deletion to DB.

Example:

class A {
Set<B> bSet;
//other properties and access (get/set) methods
}

class B {
//properties and access (get/set) methods
}

Executing the following sentences must remove b element from database. The only way I know to do that is with CascadeType.DELETE_ORPHAN annotation in A.setB property.

A.getBSet().remove(b);
saveOrUpdate(a);

In this scenario I can't to call delete method for b object, so I could "intercept" or "listen" the delete action in a preDelete event listener.

It seems like you might be overcomplicating something. Without seeing why you need to call a deleteObject method before you delete an object it's hard to know.

If you delete an annotated pojo then the pojo is deleted. If you cascade then all the children are deleted. If there is something else you need to delete perhaps it should be attached to your annotated hierarchy as another child.

Pojo's actually are supposed to be just pojo's. They aren't supposed to contain any business logic.

Perhaps if you are trying to log something in the deleteObject or archive it, then you should wrap the 2 actions in a transaction and execute them simultaneously. This type of logic is usually done at a higher layer in the dao, in a manager or something similar.

I hate to do research for people but is this what your looking for

http://www.hibernate.org/hib_docs/refer ... vents.html

First of all, I want to thank you for the research. I'm not sure if what you have found is what I need. I had written an event before to publish the topic, but it did not work fine...

I'm going to clarify definitely the situation.



Like M-N relation has attributes, I need to write a class for it.
Notice that relation is unidirectional, I mean, A side looks B (via AB attribute) but B side can't see A side. This is not negotiable.

Now, what happens if I try to delete a B element? if I call delete method in B DAO, it would be responsible to update attribute A.setB, deleting AB elements.

The real problem comes when a B element in deleted in cascade by a parent element. So I need to intercept the deletion and defer A entities form B setting null values and deleting AB elements.

Is now the scenario complete? do you understand what I am oing and why I need to intercept the action?

Like I wrote at the beginning of the topic, DAO calls in a preDelete event does not work and I don't know why.

Any other comment or help about this?

Best regards.

The interceptor seems to be what you want. You might want to post a new topic so somebody can help you with the problem you are having with that. I have never used them so, I could only guess at it..

I still think that you can simplify this simply by adding the logic to your manager layer. There is no reason why you could not delete B and then go back and remove all AB's where b doesn't exist. Or just delete AB where it has the fk of the previously delted b.

I can't say I am an expert on hibernate, but i don't believe that what your doing will be executed atomically anyway. Unless of course you put it all in a transaction which you could do in your manager layer anyway.

Finally I have reached my mark!!!

Now I'm using an interceptor http://www.hibernate.org/hib_docs/reference/en/html/events.html and it works just like I was looking for. This is: just before make effective any object deletion, I can intercept the execution flow and run sentences doing what I need.

The only extra considretaion is, like those actions access to the DB, i need a hibernate session/transaction and it MUST be a new session, I mean, I have to use REQUIRES_NEW instead REQUIRED propagation.

Glad you found a solution to your problem.