It's not modified from the database point of view, but it's modified
from the Java perspective. A's toMany list is different, and those
changes eventually have to be propagated to other DataContexts.
At least, I'm guessing that's the justification.
I could see an argument for the other side too, though.
On 9/12/05, Kevin Menard <kmenar..ervprise.com> wrote:
> Hey all,
>
> I guess I'm not totally understanding what qualifies as a modified
> object. Say I have two objects, A and B. A relationship exists
> between A and B, but A has no references to B -- it's purely a
> Cayenne convenience thing.
>
> So, I call A.addAnotherB(B). The B has not been committed to the
> database yet and A already exists in the database. At this point, A
> is marked as modified despite the fact nothing about it is going to
> change in the database. So, what makes it modified?
>
> This is screwing me up a bit because I've overridden validateForSave
> () in A to prevent two A's from having the same column value for some
> column (it's flagged as unique, but this prevents me from having to
> mess around with Cayenne exception). It works like a charm on
> inserts or if an A instance attempts to change that value to a
> conflicting one. However, it's also causing validation to fail in
> the case that I've outlined above.
>
> So, any clarification would be greatly appreciated.
>
> Thanks,
> Kevin
>
This archive was generated by hypermail 2.0.0 : Mon Sep 12 2005 - 14:31:09 EDT