Wow, thanks Fabio! That's exactly what I wanted. In fact we solved our problem by cloning the code in AbstractFlushingEventListener and modifying its behavior, but this feels so much cleaner.
:) /G 2011/5/20 Fabio Maulo <[email protected]> > In the trunk AbstractFlushingEventListener was relaxed ;) > > > On Fri, May 20, 2011 at 12:07 PM, Fabio Maulo <[email protected]>wrote: > >> Gunnar, >> you can implement your own FlueshEvent and override the NH3.1 behavior (it >> is easy). >> >> >> On Fri, May 20, 2011 at 11:21 AM, Gunnar Liljas >> <[email protected]>wrote: >> >>> Thanks Fabio and Julian! I'm closer to enlightenment. I guess I have to >>> dig into the code a bit more to get a clear picture of what happens behind >>> the scenes. The "set readonly on load" thing is of course a hack, so that it >>> can stop working should be expected. >>> >>> /G >>> >>> >>> 2011/5/20 Fabio Maulo <[email protected]> >>> >>>> Gunnar, >>>> is the section 12.2, table 12.1 >>>> >>>> >>>> On Fri, May 20, 2011 at 10:06 AM, Julian Maughan < >>>> [email protected]> wrote: >>>> >>>>> That is the question I was attempting to answer... The basic answer is >>>>> that in some circumstances, the cascade is required for read-only >>>>> entities. >>>>> The documentation says in what circumstances the cascade is performed. For >>>>> example, on flush a cascade will be performed on a read-only entity that >>>>> has >>>>> a unidirectional one-to-many association because the collection can >>>>> contain >>>>> entities that are not read-only. >>>> >>>> >>>> >>>> >>>> -- >>>> Fabio Maulo >>>> >>>> >>> >> >> >> -- >> Fabio Maulo >> >> > > > -- > Fabio Maulo > >
