So in your tests does a read-only object with "phantom" modification
blow on commit with an exception? If so, we need to open a bug report
and handle it in the commit code.
BTW, now I am investigating changing the object state tracking
mechanism to be object-based, not snapshot-based. If this works out
we may revisit this issue again later.
Andrus
On Jan 25, 2006, at 9:52 AM, Cris Daniluk wrote:
> In CayenneDataObject, I believe the persistenceState is being
> prematurely set to MODIFIED:
>
> public void writeProperty(String propName, Object val) {
> resolveFault();
>
> // 1. retain object snapshot to allow clean changes tracking
> // 2. change object state
> if (persistenceState == PersistenceState.COMMITTED) {
> persistenceState = PersistenceState.MODIFIED;
> dataContext.getObjectStore().retainSnapshot(this);
> }
> // else....
> // other persistence states can't be changed to MODIFIED
>
> writePropertyDirectly(propName, val);
> }
>
> If the value mapped to propName is already val, this will trigger a
> MODIFIED. It won't trigger a write, because of the optimistic updates,
> but it will still blow up if the object is readonly.
>
> I think the read-only error should only happen if the snapshots are
> different, or the state should not be set to MODIFIED until a
> difference is verified. This isn't as much of a problem in
> writeProperty (which makes a better example) as it is in
> addToManyTarget. Right now, unless I delete the reverse relationship
> from a readonly object in the modeler, when I add a relation to the
> writable object, it triggers the reverse relationship and sets the
> state to MODIFIED, even though no database write is required. That
> seems to limit the value of readonly...
>
> Cris
>
This archive was generated by hypermail 2.0.0 : Wed Jan 25 2006 - 11:57:45 EST