Hi Maik, This bug affected only the case when LifecycleListener interface where explicitly used (in method addListener(Class, LifecycleListener)), not the case when custom listeners with annotated methods are used. As I understand this is not a very popular usage pattern.
On Thu, Apr 6, 2017 at 2:37 PM, Musall, Maik <[email protected]> wrote: > Hi again, > > could this just have been this bug that Nikita fixed yesterday? > > https://issues.apache.org/jira/browse/CAY-2276 > <https://issues.apache.org/jira/browse/CAY-2276> > > Maik > > >> Am 03.03.2017 um 17:48 schrieb Andrus Adamchik <[email protected]>: >> >> Yeah, we'd need to do some forensics on this. I no longer remember how this >> change occurred. Could've been a bug that got legitimized via CAY-2039 ... >> or not. Also, to add some context to this, we wanted to merge validation and >> callback mechanisms in one. This got excluded from 4.0 scope though. Perhaps >> past 4.0 we'll come up with some universal callback mechanism, free of JPA >> heritage. >> >> Andrus >> >>> On Mar 3, 2017, at 5:13 PM, [email protected] wrote: >>> >>> Created JIRA CAY-2254 >>> >>> >>> -----Original Message----- >>> From: Musall, Maik >>> Sent: Thursday, March 2, 2017 10:49 AM >>> To: [email protected] >>> Subject: Re: Validation and @PrePersist >>> >>> Hi Jurgen, >>> >>>> Am 02.03.2017 um 09:33 schrieb [email protected]: >>>> >>>> I agree with your reasoning. So then the original description of how >>>> lifecycle events should behave in 3.1 is conceptually better (i.e. that >>>> PrePersist & PreUpdate occur before validation), and the historical >>>> behaviour is then a bug ? >>> >>> That would be my conclusion, too. >>> >>>> It would be good for this to be changed, unless there's backward >>>> compatibility issues :-) >>> >>> Well, there's no better time to change this than at the beginning of M6, >>> right? :-) >>> >>> Maik >>> >>> >>>> >>>> -----Original Message----- From: Musall, Maik >>>> Sent: Thursday, March 2, 2017 9:53 AM >>>> To: [email protected] >>>> Subject: Re: Validation and @PrePersist >>>> >>>> Hi Jurgen, >>>> >>>> PostAdd is fine for seting a createDate, but what about an updateDate or >>>> something similar? If these assertions are all true: >>>> >>>> 1. validation is supposed to not change attributes >>>> 2. no more changes should be made after validation happened >>>> 3. PrePersist runs after validation >>>> >>>> then there is just no place left to set something like an updateDate. >>>> Also, PrePersist would be restricted to do read-only checks that you can >>>> also do during validation, which makes no sense to me conceptually. >>>> >>>> Maik >>>> >>>> >>>> >>>>> Am 02.03.2017 um 07:56 schrieb [email protected]: >>>>> >>>>> Hi All >>>>> >>>>> We had a similar discussion Sept-Oct 2012 where it was noted that there >>>>> was a discrepancy between the docs and the implementation. That was with >>>>> 3.1B where the behaviour was the same as it is now, i.e. validation >>>>> occurs before PrePersist (but as noted by Michael the 3.1 docs >>>>> incorrectly state "after" ). >>>>> >>>>> So I assume that subsequently the docs were updated for cayenne 4 to >>>>> correctly reflect the behaviour. >>>>> >>>>> Back then it was stated that PostAdd was the correct place to do this >>>>> kind of thing, which I think is fine for fields that have standard >>>>> default values. >>>>> >>>>> It can get a bit clumsy sometimes where you sometimes have to have both >>>>> PostAdd and PrePersist doing the same thing. For example for a timestamp >>>>> field where object entity creation (PostAdd) occurs much earlier than the >>>>> commit (PrePersist), but you want the commit timestamp. This is where I >>>>> would have preferred the behaviour that Hugi is looking for where >>>>> PrePersist is called first, before validation. >>>>> >>>>> Cheers, >>>>> Jurgen >>>>> >>>>> >>>>> -----Original Message----- From: Michael Gentry >>>>> Sent: Wednesday, March 1, 2017 5:38 PM >>>>> To: Cayenne Users >>>>> Subject: Re: Validation and @PrePersist >>>>> >>>>> Hi Hugi, >>>>> >>>>> I was indeed looking at < 4. No idea why the change was made. Perhaps >>>>> someone else can answer that one... >>>>> >>>>> Thanks, >>>>> >>>>> mrg >>>>> >>>>> >>>>> On Wed, Mar 1, 2017 at 10:03 AM, Hugi Thordarson <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Michael, >>>>>> the documentation was apparently changed for 4.0 in 2015 to reflect the >>>>>> current behaviour: >>>>>> >>>>>> https://github.com/apache/cayenne/commit/5bb12cd36f0d87e3b217cdc20c22a0 >>>>>> f6dc9613f3#diff-5b9a57288e30ef9855d80a63a812ec4f >>>>>> >>>>>> Cheers, >>>>>> - hugi >>>>>> >>>>>> >>>>>>> On 1. mar. 2017, at 14:59, Michael Gentry <[email protected]> wrote: >>>>>>> >>>>>>> Hi Hugi, >>>>>>> >>>>>>> If validateForInsert() is being called before PrePersist, we have a >>>>>>> disconnect between the documentation and the behavior you are seeing: >>>>>>> >>>>>>> "PrePersist: right before a new object is committed, inside >>>>>>> ObjectContext.commitChanges() and ObjectContext.commitChangesToParent() >>>>>>> (and prior to validateForInsert())." >>>>>>> >>>>>>> What version of Cayenne are you using? I wonder if something has > > >>>>>>> changed >>>>>>> or if the documentation is just wrong. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> mrg >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 1, 2017 at 6:18 AM, Hugi Thordarson <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> I have some logic in a Listener that uses @PrePersist to populate the >>>>>>>> value of a required attribute before committing changes. Turns out >> >>>>>>>> this >>>>>>>> doesn’t work, since Cayenne invokes validateForInsert() before running >>>>>>>> @PrePersist. >>>>>>>> >>>>>>>> Any suggestions for where I can invoke logic populates required values >>>>>>>> before validation? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> - hugi >>>>>> >>>>> >>>> >> > -- Best regards, Nikita Timofeev
