On Sat, Mar 12, 2011 at 3:43 AM, Andrus Adamchik <[email protected]> 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
mrg
PS. Would has*Changes() fix Embeddables, too? (Although I'm actually
trying to get rid of the ones in the current project.)
