cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musall, Maik" <m...@selbstdenker.ag>
Subject Re: Validation and @PrePersist
Date Thu, 04 May 2017 09:52:41 GMT
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 <ntimofeev@objectstyle.com>:
> 
> 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
> <ntimofeev@objectstyle.com> 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 <maik@selbstdenker.ag> 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 <andrus@objectstyle.org>:
>>>> 
>>>> 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, dollj@xsinet.co.za wrote:
>>>>> 
>>>>> Created JIRA CAY-2254
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Musall, Maik
>>>>> Sent: Thursday, March 2, 2017 10:49 AM
>>>>> To: user@cayenne.apache.org
>>>>> Subject: Re: Validation and @PrePersist
>>>>> 
>>>>> Hi Jurgen,
>>>>> 
>>>>>> Am 02.03.2017 um 09:33 schrieb dollj@xsinet.co.za:
>>>>>> 
>>>>>> 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: user@cayenne.apache.org
>>>>>> 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 dollj@xsinet.co.za:
>>>>>>> 
>>>>>>> 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 <hugi@godurkodi.is>
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 <blacknext@gmail.com>
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 <hugi@godurkodi.is>
>>>>>>>> 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


Mime
View raw message