From: Markus Fuchs <Markus.Fuchs_at_Sun.COM>
Date: Fri, 30 Mar 2007 15:57:21 -0700

Hi Gordon,

thanks for your answers to my questions today. My current code fixes the situation described in issue 1597 and all entity-persistence tests pass. It handles cascading the remove operation for OneToOne and OneToMany bi-directional self relationships. The code doesn't look very clean yet, but I'll work on that. It would be great, if you could run TopLink's internal tests!

Thanks,

-- markus.

Gordon Yorke wrote:

Hello Markus,
   You called earlier this afternoon, how can I help?
--Gordon

-----Original Message-----
From: Markus.Fuchs@Sun.COM [mailto:Markus.Fuchs@Sun.COM]On Behalf Of
Markus Fuchs
Sent: Monday, March 26, 2007 9:31 PM
To: Gordon Yorke
Cc: persistence@glassfish.dev.java.net
Subject: Re: Questions about 1597 implementation


Hi Gordon,

Another update is attached. If you have time, please check the following 
classes:

src/java/oracle/toplink/essentials/internal/queryframework/CallQueryMechanism.java
src/java/oracle/toplink/essentials/internal/queryframework/DatabaseQueryMechanism.java
src/java/oracle/toplink/essentials/internal/queryframework/DatasourceCallQueryMechanism.java
src/java/oracle/toplink/essentials/mappings/ObjectReferenceMapping.java
src/java/oracle/toplink/essentials/mappings/ForeignReferenceMapping.java
src/java/oracle/toplink/essentials/queryframework/WriteObjectQuery.java

I've marked questions with // TODO: ask Gordon:

Thanks!

-- markus.

Markus Fuchs wrote:
  

Hi Gordon,

please find my updated implementation attached. Now, there's only one 
test failing,

EntityManagerJUnitTestSuite.testIgnoreRemovedObjectsOnDatabaseSync

This test leaves a lock on the database and should be commented out 
when running entity-persistence-tests.

Thanks,

-- markus.

Markus Fuchs wrote:
    

Hi Gordon,

please find my updated implementation attached. Cascading deletes for 
simple OneToOne and OneToMany self-relationships (like the one 
mentioned in issue 1597) can now be handled. Many of the changes are 
due to the fact that DeleteObjectQuery now extends WriteObjectQuery, 
as I changed the method declarations from a DeleteObjectQuery to 
WriteObjectQuery.

I get 33 failures running entity-persistence-tests, which I haven't 
investigated yet. Please take a look. I marked some open questions by
   // TODO: ...

and hope, we can discuss them by phone! My main questions are:

1. Do we continue to check for the owning / non-owning relationship 
side in ForeignReferenceMapping.shouldObjectModifyCascadeToParts, or 
can this be done the pre-/post- insert/update/delete methods?
2. Can we skip calculating ChangeSets for deleted object?

Thanks,

-- markus.

Markus Fuchs wrote:
      

Hi Gordon,

I have a couple of questions about the implementation for issue 
1597. Could you please take a look?

1. Why have all the queries in DescriptorQueryManager the property 
isUserDefined == true? Other (non-cached) queries created during 
commit have isUserDefined == false. Can the queries in 
DescriptorQueryManager be user-defined? (This is resolved, but I'm 
wondering what the property isUserDefined means...)
2. Does preDelete have to distinguish between the owning / 
non-owning side of the relationship?
3. Does preDelete have to distinguish between privatly owned/non 
privately owned parts?
4. What if the referenced side is removed first in a uni-directional 
relationship? (The referenced side doesn't know, if there is a 
referencing instance)

My current implementation is attached, if you're interested.

Thanks!

-- markus.