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