Hi Nikita, thanks for completing the investigation on this. I have workarounds in place and am totally ok to have this tackled not before 4.1.
Maik > Am 04.05.2017 um 11:39 schrieb Nikita Timofeev <[email protected]>: > > Hi all, > > I've dived into this problem and it seems that there is > no simple (and more importantly safe) solution > and I propose to postpone this change until 4.1. > > Here is some details for the curious ones :) > > Currently validation is done by DataContext (either when flushing > changes to DataDomain or to parent context) while callbacks > are performed inside DataDomain's filters (namely inside TransactionFilter). > And just moving those parts into one place produce > a lot of possible incompatibilities: > 1. When pushing validation down to filters we still need it to be performed > when flushing to parent context and moreover validation relies on GraphDiff > implementation that is unknown to filters. > 2. When pulling callbacks to DataContext filters that rely on them > will stop working (like CacheInvalidationFilter or old AuditableFilter). > > On Thu, Apr 6, 2017 at 3:05 PM, Nikita Timofeev > <[email protected]> wrote: >> 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 > > > > -- > Best regards, > Nikita Timofeev
