Hibernate events plugin v0.3

8 Responses to “Hibernate events plugin v0.3”

1. trungsi Says:
   April 4th, 2008 at 9:20 am

   Thanks for this useful plugin.

   But I found some bugs. The first one is i have to prefix with “this.” to access domain entity inside event closures (beforeInsert,…).

   The second one is assigned or modified domain properties in beforeXXX closures are not updated :(.

2. Kevin Burke Says:
   April 4th, 2008 at 12:46 pm

   What up trungsi. Actually the beforeXXX methods, aside from beforeSave, are all provided by Grails. So you might want to take that up with them. If you see this happening with beforeSave let me know. I will look into the other prefixing with “this” issue.

3. Kevin Burke Says:
   April 7th, 2008 at 10:05 am

   Hi Trungsi. I couldn’t reproduce the “this” issue. If you’re still interested, could you give me some more detail on your setup.

4. trungsi Says:
   April 9th, 2008 at 2:11 pm

   Kevin,

   After checking my code, “this” is demanded to reference injected objects only in before(Insert,Update,Delete). As you said, this is not part of your plugin.

   Sorry for false alert

5. Shawn Hartsock Says:
   April 16th, 2008 at 2:40 pm

   Okay, so I’m finally looking at this plugin now. I see how in the HibernateEventsListener class you strip out the object/entity from the event and use that to call the closure. As a result the closure doesn’t know anything about the event or the previous state of the object. Why not expose the entire event object to the closure?

   I need to research what the object state is as it is referenced by the event. It should depend on the event being fired but certain events should have the object’s state before the event fired… for example that’s the only way the “afterDelete” could function. It’s one of these previous value states that I need to be able to examine in context of the current values in the object.

   In a database trigger we can see the value of the columns before and after the triggered event. I can compare these and do other inserts and updates based on logic inside the trigger. This is what I hoped to do in these closures. Without knowledge of the previous and current (or upcoming) states… and the ability to compare them… I’m afraid that idea’s just a tad sunk.

6. Kevin Burke Says:
   April 16th, 2008 at 5:09 pm

   Well I did this for a couple of reasons. The first is that it fit my need. I just needed to be informed that database interactions had occurred. For instance I use the afterInsert to save a file to disk after it’s metadata has been persisted to the db. I also use afterDelete to remove the file from disk after it’s medadata has been deleted from the db. The other reason was to just simplify the interface. I was supposing that the current model would cover a large percentage of use cases. I suppose that I supposed wrongly.

   I can definitely see the value in what you’re asking for. Do you propose that the callback events work completely analogous to the hibernate events api? How would you like to see it implemented?

7. Shawn Hartsock Says:
   April 20th, 2008 at 8:16 pm

   Sorry to run off and just post things without talking to you first but I’m on a tight dead-line. I’ve posted the result of my modifications to my blog. You can examine what I did. It’s rough but what I need is known as Audit Logging or Audit Trails. I’ve been over Nabble.com a few times trying to see if anyone else needed this. I didn’t find anything.

   So I’ve created a variant of your Hibernate Events plugin that provides Audit logging. I was shocked at how easy it was to work in this space. I’ve only had two working days to play with this configuration but it appears to work alright. You can download it and see exactly what I was talking about. In my project what changed and what values that object assumes determine which of many different semi-intelligent behaviors the overall system needs to exhibit.

   Previously, I would have done this with PL/SQL or other in-database event triggers. I think this will feel much more natural to tie everything to the domain object and services via these handlers. For one thing it keeps all programming logic in one language and one code base. You don’t have to coordinate system designs around several different programming paradigms.

   And, by the way, thanks. I wouldn’t have figured out about six critical lines with out your example. I didn’t know anything about Hibernate events or grails plug-ins until Thursday. I’ve still got one major problem… how to generically determine the actor without specifically depending on Acegi, CAS, or Crowd. I’ll figure something out…

8. Kevin Burke Says:
   April 22nd, 2008 at 7:39 am

   Right on. Sounds like you’ve got a very useful plugin there. Thanks for the follow up.

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website