Delete rules

[Kevin Menard <km...@servprise.com>]

Howdy.

I've just run into an issue with some of my cascading delete rules.  Trying
to reproduce the problem has been difficult because the ordering seems to be
non-deterministic.  Looking at the source, it looks like the delete
operations are stored in a Map that has no internal ordering of the keyset.

DataContextDeleteAction#deleteNew() and
DataContextDeleteAction#deletePersistent() also process the delete rules in
a different order.  As it turns out, it may not matter much.

Is this assessment accurate?  If so, we probably should always process
delete rules first, then the current node, using a DFS to handle the
creation of the delete queries.  If the assessment is not accurate, any help
in understanding what may cause spurious issues with cascading deletes would
be appreciated.

-- 
Thanks,
Kevin

Re: Delete rules

[Kevin Menard <km...@servprise.com>]

On the commit.  What I have is something similar to the following:

A -- 1:* -- B
|--- 1:1 -- B (default)
|--- 1:* -- C
|--- 1:1 -- C (default)

Odd schema, I know.

What I have is a Cascade set up on A to delete all B and C, since they
really shouldn't exist without an A.  On the two default fields, I have "No
Action" set up.

What I'm seeing is some cases where it deletes all Bs then all Cs then all
As and everything works fine.  Sometimes though, it deletes all Bs then all
As and fails because Cs cannot exist without As.  Looking at the object
store, the deletes for C exist, but they're further down than the As.

But, I do have a circular dependency here, so perhaps that is the root of
the problem.  If that be the case, I can either fix it with DB rules or by
foregoing the delete rules in Cayenne and using lifecycle callbacks.

-- 
Kevin

On 10/22/07 4:56 PM, "Andrus Adamchik" <an...@objectstyle.org> wrote:

> Kevin,
> 
> what kind of problems? During the deletion or the subsequent commit?
> 
> If that's on commit, the ordering is determined using dependency
> graph analysis with AshwoodEntitySorter (i.e. not dependent on the
> order of delete rules processing). It works well except for circular
> relationships.
> 
> Andrus
> 
> 
> On Oct 22, 2007, at 11:35 PM, Kevin Menard wrote:
>> Howdy.
>> 
>> I've just run into an issue with some of my cascading delete
>> rules.  Trying
>> to reproduce the problem has been difficult because the ordering
>> seems to be
>> non-deterministic.  Looking at the source, it looks like the delete
>> operations are stored in a Map that has no internal ordering of the
>> keyset.
>> 
>> DataContextDeleteAction#deleteNew() and
>> DataContextDeleteAction#deletePersistent() also process the delete
>> rules in
>> a different order.  As it turns out, it may not matter much.
>> 
>> Is this assessment accurate?  If so, we probably should always process
>> delete rules first, then the current node, using a DFS to handle the
>> creation of the delete queries.  If the assessment is not accurate,
>> any help
>> in understanding what may cause spurious issues with cascading
>> deletes would
>> be appreciated.
>> 
>> -- 
>> Thanks,
>> Kevin
>> 
>> 
> 

-- 

Re: Delete rules

[Andrus Adamchik <an...@objectstyle.org>]

Kevin,

what kind of problems? During the deletion or the subsequent commit?

If that's on commit, the ordering is determined using dependency  
graph analysis with AshwoodEntitySorter (i.e. not dependent on the  
order of delete rules processing). It works well except for circular  
relationships.

Andrus


On Oct 22, 2007, at 11:35 PM, Kevin Menard wrote:
> Howdy.
>
> I've just run into an issue with some of my cascading delete  
> rules.  Trying
> to reproduce the problem has been difficult because the ordering  
> seems to be
> non-deterministic.  Looking at the source, it looks like the delete
> operations are stored in a Map that has no internal ordering of the  
> keyset.
>
> DataContextDeleteAction#deleteNew() and
> DataContextDeleteAction#deletePersistent() also process the delete  
> rules in
> a different order.  As it turns out, it may not matter much.
>
> Is this assessment accurate?  If so, we probably should always process
> delete rules first, then the current node, using a DFS to handle the
> creation of the delete queries.  If the assessment is not accurate,  
> any help
> in understanding what may cause spurious issues with cascading  
> deletes would
> be appreciated.
>
> -- 
> Thanks,
> Kevin
>
>