You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by John Huss <jo...@gmail.com> on 2013/05/22 16:57:38 UTC
Problem with postLoad callback and faulting
I've tracked down a problem. The situation is I have a postLoad callback
on an entity that calls a setter on the object, for example:
public void publicCallback(Object entity) {
Artist a = (Artist)entity;
a.setArtistName("Changed");
}
This works if you fetch the object directly with a SelectQuery. But if you
fault in the object through a relationship it will call
BaseContext.prepareForAccess which has this:
// sanity check...
if (object.getPersistenceState() != PersistenceState.COMMITTED)
{
String state = PersistenceState.persistenceStateName(object
.getPersistenceState());
// TODO: andrus 4/13/2006, modified and deleted states are
possible due to
// a race condition, should we handle them here?
throw new FaultFailureException(...
}
Since the object is modified (not committed) an exception is thrown. I
have a test case written to demonstrate the problem, but I'm not sure what
the best solution is. I think it is valid to allow mutating an object
during postLoad. Thoughts?
Thanks,
John
Re: Problem with postLoad callback and faulting
Posted by Andrus Adamchik <an...@objectstyle.org>.
+1
On May 30, 2013, at 2:29 AM, John Huss <jo...@gmail.com> wrote:
> All the unit tests pass after commenting it out. Commit it?
>
> On Sunday, May 26, 2013, Andrus Adamchik wrote:
>
>>> I think it is valid to allow mutating an object during postLoad.
>>
>> Agreed.
>>
>> This whole "sanity check" block smells. Maybe just remove it and see what
>> unit tests would fail?
>>
>> A.
>>
>> On May 22, 2013, at 5:57 PM, John Huss <johnthuss@gmail.com <javascript:;>>
>> wrote:
>>
>>> I've tracked down a problem. The situation is I have a postLoad callback
>>> on an entity that calls a setter on the object, for example:
>>>
>>> public void publicCallback(Object entity) {
>>> Artist a = (Artist)entity;
>>> a.setArtistName("Changed");
>>> }
>>>
>>> This works if you fetch the object directly with a SelectQuery. But if
>> you
>>> fault in the object through a relationship it will call
>>> BaseContext.prepareForAccess which has this:
>>>
>>> // sanity check...
>>> if (object.getPersistenceState() !=
>> PersistenceState.COMMITTED)
>>> {
>>>
>>> String state =
>> PersistenceState.persistenceStateName(object
>>> .getPersistenceState());
>>>
>>> // TODO: andrus 4/13/2006, modified and deleted states are
>>> possible due to
>>> // a race condition, should we handle them here?
>>>
>>> throw new FaultFailureException(...
>>> }
>>>
>>> Since the object is modified (not committed) an exception is thrown. I
>>> have a test case written to demonstrate the problem, but I'm not sure
>> what
>>> the best solution is. I think it is valid to allow mutating an object
>>> during postLoad. Thoughts?
>>>
>>> Thanks,
>>> John
>>
>>
Re: Problem with postLoad callback and faulting
Posted by John Huss <jo...@gmail.com>.
All the unit tests pass after commenting it out. Commit it?
On Sunday, May 26, 2013, Andrus Adamchik wrote:
> > I think it is valid to allow mutating an object during postLoad.
>
> Agreed.
>
> This whole "sanity check" block smells. Maybe just remove it and see what
> unit tests would fail?
>
> A.
>
> On May 22, 2013, at 5:57 PM, John Huss <johnthuss@gmail.com <javascript:;>>
> wrote:
>
> > I've tracked down a problem. The situation is I have a postLoad callback
> > on an entity that calls a setter on the object, for example:
> >
> > public void publicCallback(Object entity) {
> > Artist a = (Artist)entity;
> > a.setArtistName("Changed");
> > }
> >
> > This works if you fetch the object directly with a SelectQuery. But if
> you
> > fault in the object through a relationship it will call
> > BaseContext.prepareForAccess which has this:
> >
> > // sanity check...
> > if (object.getPersistenceState() !=
> PersistenceState.COMMITTED)
> > {
> >
> > String state =
> PersistenceState.persistenceStateName(object
> > .getPersistenceState());
> >
> > // TODO: andrus 4/13/2006, modified and deleted states are
> > possible due to
> > // a race condition, should we handle them here?
> >
> > throw new FaultFailureException(...
> > }
> >
> > Since the object is modified (not committed) an exception is thrown. I
> > have a test case written to demonstrate the problem, but I'm not sure
> what
> > the best solution is. I think it is valid to allow mutating an object
> > during postLoad. Thoughts?
> >
> > Thanks,
> > John
>
>
Re: Problem with postLoad callback and faulting
Posted by Andrus Adamchik <an...@objectstyle.org>.
> I think it is valid to allow mutating an object during postLoad.
Agreed.
This whole "sanity check" block smells. Maybe just remove it and see what unit tests would fail?
A.
On May 22, 2013, at 5:57 PM, John Huss <jo...@gmail.com> wrote:
> I've tracked down a problem. The situation is I have a postLoad callback
> on an entity that calls a setter on the object, for example:
>
> public void publicCallback(Object entity) {
> Artist a = (Artist)entity;
> a.setArtistName("Changed");
> }
>
> This works if you fetch the object directly with a SelectQuery. But if you
> fault in the object through a relationship it will call
> BaseContext.prepareForAccess which has this:
>
> // sanity check...
> if (object.getPersistenceState() != PersistenceState.COMMITTED)
> {
>
> String state = PersistenceState.persistenceStateName(object
> .getPersistenceState());
>
> // TODO: andrus 4/13/2006, modified and deleted states are
> possible due to
> // a race condition, should we handle them here?
>
> throw new FaultFailureException(...
> }
>
> Since the object is modified (not committed) an exception is thrown. I
> have a test case written to demonstrate the problem, but I'm not sure what
> the best solution is. I think it is valid to allow mutating an object
> during postLoad. Thoughts?
>
> Thanks,
> John