I will be implementing a feature to update an id in a table after Hibernate does my deletes. But I want to get some feedback on which approach is better. Also the table I am updating the value in, Hibernate doesn't know about it so I would have to do a straight jdbc update -- is that even possible.
views:
103answers:
1
A:
As far as using listener / interceptor goes, I'd go with listener - it's more flexible in terms of events that can be listened to. Interceptor's primary purpose is to inspect / alter object properties prior to some event (e.g. deletion); whereas listener can be configured to listen to "PostDelete" event or many others.
However, if said table is not mapped why do you need either? You can instead update it directly in your code after you've called delete() (or after you've called flush() if there's a foreign key involved).
You can also do that in a trigger (possibly; depending on whether necessary information is available in the database, of course).
ChssPly76
2009-10-09 21:11:00
Well hibernate sees a view and I need to pass in a session id on the delete which I can't pass in on the where clause. So when hibernate does the delete on the view an "instead of" trigger runs but after this runs I need some way of passing the session id for the person who just did the delete into the view's base table as a form of audit. But this base table hibernate knows nothing of, so on @PostDelete can I do an insert/update on a non orm-ed table?
non sequitor
2009-10-10 07:21:08
Will try it out come Mon
non sequitor
2009-10-10 07:24:25
@PostDeleteEvent (passed to your listener) extends from AbstractEvent (https://www.hibernate.org/hib_docs/v3/api/org/hibernate/event/AbstractEvent.html) which has a getSession() method. So you can either use a `createSQLQuery()` or define your SQL as named query and use `getNamedQuery()`, set the necessary parameters and execute it. I haven't tried this in PostDeleteListener specifically, but I don't see why it wouldn't work.
ChssPly76
2009-10-10 15:49:35