Validation and @PrePersist

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Validation and @PrePersist

Hugi Thordarson-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

dollj
Hi Hugi

For this kind of thing use @PostAdd instead.

Regards
Jurgen


-----Original Message-----
From: Hugi Thordarson
Sent: Wednesday, March 1, 2017 1:18 PM
To: [hidden email]
Subject: Validation and @PrePersist

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Hugi Thordarson-2
Hi Jurgen,
fine suggestion but unfortunately not the part of the lifecycle I need to catch—the action needs to be performed before committing, not after adding (so basically I need @PrePersist—but I need it before validation happens).

Cheers,
- hugi


> On 1. mar. 2017, at 13:14, <[hidden email]> <[hidden email]> wrote:
>
> Hi Hugi
>
> For this kind of thing use @PostAdd instead.
>
> Regards
> Jurgen
>
>
> -----Original Message----- From: Hugi Thordarson
> Sent: Wednesday, March 1, 2017 1:18 PM
> To: [hidden email]
> Subject: Validation and @PrePersist
>
> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Adam Boyle
I'd like to second this suggestion. There have been several instances that I've made required fields nullable solely because validation occurs prior to the @PrePersist lifecycle callback.

________________________________
From: Hugi Thordarson <[hidden email]>
Sent: Wednesday, March 1, 2017 8:51:48 AM
To: [hidden email]
Subject: Re: Validation and @PrePersist

Hi Jurgen,
fine suggestion but unfortunately not the part of the lifecycle I need to catch—the action needs to be performed before committing, not after adding (so basically I need @PrePersist—but I need it before validation happens).

Cheers,
- hugi


> On 1. mar. 2017, at 13:14, <[hidden email]> <[hidden email]> wrote:
>
> Hi Hugi
>
> For this kind of thing use @PostAdd instead.
>
> Regards
> Jurgen
>
>
> -----Original Message----- From: Hugi Thordarson
> Sent: Wednesday, March 1, 2017 1:18 PM
> To: [hidden email]
> Subject: Validation and @PrePersist
>
> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Michael Gentry
In reply to this post by Hugi Thordarson-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Hugi Thordarson-2
Hi Michael,
the documentation was apparently changed for 4.0 in 2015 to reflect the current behaviour:

https://github.com/apache/cayenne/commit/5bb12cd36f0d87e3b217cdc20c22a0f6dc9613f3#diff-5b9a57288e30ef9855d80a63a812ec4f

Cheers,
- hugi


> On 1. mar. 2017, at 14:59, Michael Gentry <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Michael Gentry
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Matt Watson
In reply to this post by Hugi Thordarson-2
When I ran into this same scenario I realized that “validateForInsert” was the hook I needed, instead of @PrePersist.

@Override
public void validateForInsert(ValidationResult validationResult) {
        if (getReference() == null || getReference().isEmpty()) {
                setReference(System.getNextPurchaseOrderReference());
        }
        super.validateForInsert(validationResult);
}



> On Mar 1, 2017, at 5:51 AM, Hugi Thordarson <[hidden email]> wrote:
>
> Hi Jurgen,
> fine suggestion but unfortunately not the part of the lifecycle I need to catch—the action needs to be performed before committing, not after adding (so basically I need @PrePersist—but I need it before validation happens).
>
> Cheers,
> - hugi
>
>
>> On 1. mar. 2017, at 13:14, <[hidden email]> <[hidden email]> wrote:
>>
>> Hi Hugi
>>
>> For this kind of thing use @PostAdd instead.
>>
>> Regards
>> Jurgen
>>
>>
>> -----Original Message----- From: Hugi Thordarson
>> Sent: Wednesday, March 1, 2017 1:18 PM
>> To: [hidden email]
>> Subject: Validation and @PrePersist
>>
>> 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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Musall, Maik
Hi all,

but isn't hte purpose of validation to check if the object to be saved is in a valid state? That would imply that validation has a positive (pass) or negative (ValidationException) result, and no side effects. Modifying the object during validation would defeat the purpose, wouldn't it?

Maik

> Am 01.03.2017 um 17:12 schrieb Matt Watson <[hidden email]>:
>
> When I ran into this same scenario I realized that “validateForInsert” was the hook I needed, instead of @PrePersist.
>
> @Override
> public void validateForInsert(ValidationResult validationResult) {
> if (getReference() == null || getReference().isEmpty()) {
> setReference(System.getNextPurchaseOrderReference());
> }
> super.validateForInsert(validationResult);
> }
>
>
>
>> On Mar 1, 2017, at 5:51 AM, Hugi Thordarson <[hidden email]> wrote:
>>
>> Hi Jurgen,
>> fine suggestion but unfortunately not the part of the lifecycle I need to catch—the action needs to be performed before committing, not after adding (so basically I need @PrePersist—but I need it before validation happens).
>>
>> Cheers,
>> - hugi
>>
>>
>>> On 1. mar. 2017, at 13:14, <[hidden email]> <[hidden email]> wrote:
>>>
>>> Hi Hugi
>>>
>>> For this kind of thing use @PostAdd instead.
>>>
>>> Regards
>>> Jurgen
>>>
>>>
>>> -----Original Message----- From: Hugi Thordarson
>>> Sent: Wednesday, March 1, 2017 1:18 PM
>>> To: [hidden email]
>>> Subject: Validation and @PrePersist
>>>
>>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Michael Gentry
Hi Maik,

I've historically done data manipulations in the lifecycle events
(pre-persist, post-add, post-load, etc) and not the validate methods.  I
kind of agree with you that validate shouldn't be modifying data.  I'm
hoping someone else explains the change now.  :-)

mrg


On Wed, Mar 1, 2017 at 11:43 AM, Musall, Maik <[hidden email]> wrote:

> Hi all,
>
> but isn't hte purpose of validation to check if the object to be saved is
> in a valid state? That would imply that validation has a positive (pass) or
> negative (ValidationException) result, and no side effects. Modifying the
> object during validation would defeat the purpose, wouldn't it?
>
> Maik
>
> > Am 01.03.2017 um 17:12 schrieb Matt Watson <[hidden email]>:
> >
> > When I ran into this same scenario I realized that “validateForInsert”
> was the hook I needed, instead of @PrePersist.
> >
> > @Override
> > public void validateForInsert(ValidationResult validationResult) {
> >       if (getReference() == null || getReference().isEmpty()) {
> >               setReference(System.getNextPurchaseOrderReference());
> >       }
> >       super.validateForInsert(validationResult);
> > }
> >
> >
> >
> >> On Mar 1, 2017, at 5:51 AM, Hugi Thordarson <[hidden email]> wrote:
> >>
> >> Hi Jurgen,
> >> fine suggestion but unfortunately not the part of the lifecycle I need
> to catch—the action needs to be performed before committing, not after
> adding (so basically I need @PrePersist—but I need it before validation
> happens).
> >>
> >> Cheers,
> >> - hugi
> >>
> >>
> >>> On 1. mar. 2017, at 13:14, <[hidden email]> <[hidden email]>
> wrote:
> >>>
> >>> Hi Hugi
> >>>
> >>> For this kind of thing use @PostAdd instead.
> >>>
> >>> Regards
> >>> Jurgen
> >>>
> >>>
> >>> -----Original Message----- From: Hugi Thordarson
> >>> Sent: Wednesday, March 1, 2017 1:18 PM
> >>> To: [hidden email]
> >>> Subject: Validation and @PrePersist
> >>>
> >>> 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
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

dollj
In reply to this post by Michael Gentry
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Musall, Maik
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 [hidden email]:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

dollj
Hi Maik

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 ?

It would be good for this to be changed, unless there's backward
compatibility issues  :-)

Jurgen


-----Original Message-----
From: Musall, Maik
Sent: Thursday, March 2, 2017 9:53 AM
To: [hidden email]
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 [hidden email]:
>
> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Musall, Maik
Hi Jurgen,

> Am 02.03.2017 um 09:33 schrieb [hidden email]:
>
> 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: [hidden email]
> 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 [hidden email]:
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

dollj
Created JIRA CAY-2254


-----Original Message-----
From: Musall, Maik
Sent: Thursday, March 2, 2017 10:49 AM
To: [hidden email]
Subject: Re: Validation and @PrePersist

Hi Jurgen,

> Am 02.03.2017 um 09:33 schrieb [hidden email]:
>
> 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: [hidden email]
> 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 [hidden email]:
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Andrus Adamchik
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, [hidden email] wrote:
>
> Created JIRA CAY-2254
>
>
> -----Original Message-----
> From: Musall, Maik
> Sent: Thursday, March 2, 2017 10:49 AM
> To: [hidden email]
> Subject: Re: Validation and @PrePersist
>
> Hi Jurgen,
>
>> Am 02.03.2017 um 09:33 schrieb [hidden email]:
>>
>> 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: [hidden email]
>> 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 [hidden email]:
>>>
>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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
>>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Musall, Maik
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 <[hidden email]>:
>
> 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, [hidden email] wrote:
>>
>> Created JIRA CAY-2254
>>
>>
>> -----Original Message-----
>> From: Musall, Maik
>> Sent: Thursday, March 2, 2017 10:49 AM
>> To: [hidden email]
>> Subject: Re: Validation and @PrePersist
>>
>> Hi Jurgen,
>>
>>> Am 02.03.2017 um 09:33 schrieb [hidden email]:
>>>
>>> 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: [hidden email]
>>> 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 [hidden email]:
>>>>
>>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>> 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
>>>>>
>>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Nikita Timofeev
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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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, [hidden email] wrote:
>>>
>>> Created JIRA CAY-2254
>>>
>>>
>>> -----Original Message-----
>>> From: Musall, Maik
>>> Sent: Thursday, March 2, 2017 10:49 AM
>>> To: [hidden email]
>>> Subject: Re: Validation and @PrePersist
>>>
>>> Hi Jurgen,
>>>
>>>> Am 02.03.2017 um 09:33 schrieb [hidden email]:
>>>>
>>>> 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: [hidden email]
>>>> 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 [hidden email]:
>>>>>
>>>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Nikita Timofeev
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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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, [hidden email] wrote:
>>>>
>>>> Created JIRA CAY-2254
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Musall, Maik
>>>> Sent: Thursday, March 2, 2017 10:49 AM
>>>> To: [hidden email]
>>>> Subject: Re: Validation and @PrePersist
>>>>
>>>> Hi Jurgen,
>>>>
>>>>> Am 02.03.2017 um 09:33 schrieb [hidden email]:
>>>>>
>>>>> 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: [hidden email]
>>>>> 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 [hidden email]:
>>>>>>
>>>>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Validation and @PrePersist

Musall, Maik
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 <[hidden email]>:
>
> 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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>
>>>> 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, [hidden email] wrote:
>>>>>
>>>>> Created JIRA CAY-2254
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Musall, Maik
>>>>> Sent: Thursday, March 2, 2017 10:49 AM
>>>>> To: [hidden email]
>>>>> Subject: Re: Validation and @PrePersist
>>>>>
>>>>> Hi Jurgen,
>>>>>
>>>>>> Am 02.03.2017 um 09:33 schrieb [hidden email]:
>>>>>>
>>>>>> 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: [hidden email]
>>>>>> 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 [hidden email]:
>>>>>>>
>>>>>>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>>> 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

Loading...