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.