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 > >
