+1 On May 30, 2013, at 2:29 AM, John Huss <[email protected]> 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 <[email protected] <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 >> >>
