On 28/09/09 11:08 AM, Lachlan Deck wrote:
> So from what I can see the only two changes required were 'postInsert'
> and adjusting the meaning of prePersist
I think most of the discussion started from the point that we shouldn't 'adjust' the meaning of an event which is defined by JPA since it will be confusing to users from a JPA background.
I'm not wedding to the idea I proposed: it was more to stimulate some thinking about what a completely fresh approach might look like. But thinking about it, the problem with beforeCommit as a name is that it will not have effect when committing child contexts, so it is potentially confusing.
Lachlan's idea of keeping the changes minimal might be the simplest one for users.
On 28/09/09 12:13 AM, Andrus Adamchik wrote:
> * Callbacks on contexts. Could be a good idea to have listeners attached
> to a context (although I don't see any use for context's own callback
> methods). I suggest we keep that in mind, but push it to the
> future releases to avoid adding new concepts to 3.0 at this point.
Certainly it should be postponed, but thought about now so we have a plan. The use for this type of listener is when you want to inspect the entire context before commit rather than look at the commit per object. As an example in one of our projects we added a whole lot of code server-side (ROP) on saving a new Payment object, which checked to see if it was a credit card payment and then performed some action (like contacting the bank, checking for places available, etc). But we found that when we had a free product there was no Payment, but we still wanted to check for places available. So a hook at a context level could have been useful to identify that the commit was of new enrolments/students/etc and then allow the code to check for places, process payment, etc As it is, we worked around the problem by creating a $0 Payment, just so the listener and all our code could be fired off in a consistent way.
We could have alternately created a different servlet call or used several other approaches, so it was never a big issue, just a potential use-case.
Anyhow, I've said enough about this topic and I don't want this to turn into a bikeshed... I'm happy with whatever Andrus implements, which will be a good improvement whichever way is chosen.
Ari Maniatis
----------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Sun Sep 27 2009 - 21:36:01 EDT