cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: False Modified
Date Sat, 12 Mar 2011 13:42:06 GMT
On Sat, Mar 12, 2011 at 3:43 AM, Andrus Adamchik <> wrote:
> Yeah, I totally understand how this can be useful. I am trying to analyze the situation
and just like with most things in Cayenne core it can get pretty deep.

Yeah, whenever I go into the stack it takes me a while to remember things.

> Some factors to consider:
> 1. Performance (I mentioned about that before).

I completely understand this.

> 2. "Circular changes" canceling modifications:
>  assertEquals("A", o.getP());
>  o.setP("B"); // modified
>  o.setP("A"); // modified? (property change is "canceled", but maybe other properties
are also modified)

I'd be OK with a circular change showing up as modified.  They made a
change.  Then they made another change.  I'm OK with that.  (I'm
thinking of data entry in the UI here.)

> 3. "Uncommittable changes". An example - objects with modified to-many relationships
are treated as modified, but during commit their DB records are not updated.

I'm not sure this is a big issue.  The object graph has indeed been
modified in this case.  Yes, it would be more ideal if the parent of
the to-many didn't show up when you called modifiedObjects(), but for
the boolean hasChanges(), it would work out fine.

> So I am leaning towards either a method like ObjectContext.hasCommittabledChanges() that
would do deeper analysis of the object graph, or maybe a more involved changeset API that
I started to draft under cayenne-lifecycle, that would among other things allow the caller
to obtain a more nuanced and detailed view of the graph changes (overall changes, changes
per object, committable/uncommitable changes etc.)

Would hasCommittableChanges() really add any other value over
hasChanges() if hasChanges() was "fixed"?  Or perhaps you are worried
about backward compatibility of the API?

> And there's of course we shouldn't forget ROP....

Sadly, I often do.  :-(

> Andrus


PS. Would has*Changes() fix Embeddables, too?  (Although I'm actually
trying to get rid of the ones in the current project.)

View raw message