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.