Yeah, I don't think delete rules are handled by the ContextCommit. But I
also don't think that those are checked during regression testing.
BTW, just wanted to give heads about my sorter plans. There are 3 of them
now, a little bit too many:
1. OperationSorter - our original sorter
2. RefIntegritySupport - the one used by ContextCommit
3. DefaultSorter - a refactored copy of (2)
I am planning to merge (2) into (3), well actually, just doing a simple
switch should work, they are pretty much identical. After that we can move
delete rule code from (1) to (3) and deprecate (1).
I was holding this till regression tests start working again, but I may
still do it pretty soon.
Andrus
> Just my $0.02 worth on this. With the most recent version from CVS, I
> switched to the new commit() which uses ContextCommit, and ran the
> normal unit tests. Got failures in CDOReflexiveRelDeleteTst (not sure
> if this is the same as what's happening in regression tests). Had a
> poke, and it turns out that it is Delete Rules causing problems.
> Nullify means that the code in RefIntegritySupport cannot determine the
> relationships between the objects anymore (it uses the properties which
> have just been conveniently nullified by DataContext.deleteObject).
> This may be the same problem that is tripping up the regression tests.
>
> The "solution" is in OperationSorter (been there, fixed this problem
> before) where if the related object is null according to the properties
> (readPropertyDirectly), then the fk/pk of the relationship is manually
> twiddled to find the relevant objects (Line 354-367 of
> OperationSorter).
>
> Don't know if this helps or not...
>
> Craig
This archive was generated by hypermail 2.0.0 : Wed Mar 05 2003 - 17:19:48 EST