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.