A couple of updates on this.
The example I made is wrong, as things would work as expected in that case.
The actual case is this:
class-table inheritance, Doctrine 2.x
B is subclass of A which is subclass of R.
A has a property 'c' which puts it in ManyToOne association to class C.
A::c is annotated with ondelete=CASCADE.
When an instance of 'C' associated to an instance of B (via che 'c'
property) is removed, the associated row in the table for A is removed, but
leftover rows remain in the tables for B and R. That's because there's a
constraint in the table for A that cascades deletes when rows are removed
from R, but not vice versa. B has a similar constraint towards R, but not
towards 'A'. So, rows remain in B and R.
cascading doctrine "remove" events seems to be the only way to handle this
situation, but it requires for C to be aware of A, which severly cripple OO
design. It is my understanding that once operations are in the DBMS domain,
doctrine cannot intervene, and as such there is no way to intercept
cascaded deletes enforced by the DBMS. I am wondering if it wouldn't make
sense for is-a relationships to be connected bi-directionally at the DBMS
level. In my example, removing a row from the 'R' table would remove the
corresponding rows in A and B. I don't see why removing a row from B or A
should not remove the corresponding row from R, too (and consequently, all
the rows in all the tables constituting the object). As it is, it would
seem that ondelete=CASCADE should *never* be used in subclasses when
class-table inheritance is used. If this is the case, I think it would be
better for the documentation to state this a bit more explicitly.
I'm still hoping I got something terribly wrong.
On Friday, May 16, 2014 9:07:16 PM UTC+2, Alessandro Tommasi wrote:
>
> Hi everybody. We ran into a weird issue today. We have Doctrine models
> configured for class-table inheritance.
>
> We have a model like this:
>
> Class A has a ManyToOne association to class C. At runime, instances of B
> (subclass of A) are created and associated to instances of C.
>
> I want B's to be removed automatically when the associated C is removed.
> If C features an inverse side association "a" to A that's easy: we annotate
> "C::a" with cascade={"remove"}. Now, suppose that I have no inverse side
> For example, C is part of a core library and needs (or can) not know who
> will feature associations to it. To achieve the same behavior, I cannot use
> ondelete=CASCADE on A::c, because inexplicably (to me), removing the
> associated C would leave rows in the B table without their counterpart in
> A. Is there a reason for Doctrine not to link B and A rows so that B's are
> removed when A's are removed, given that B extends A?
>
> I am having trouble maintaining consistency when removing C's, and there's
> no reason why I should have an inverse side of the relationship for a
> seemingly "no brainer" thing like removing the "child" instance row when
> the "father" one is removed. I searched the doc to no avail. It would seem
> whenever you have two entities in an is-a relationship, the child class
> should be linked to the father so that removing a row from the father table
> (e.g. removing an A object) would also delete the corresponding child table
> row (that is, also scratching the actual 'B' object).
>
> Any thoughts?!
>
--
You received this message because you are subscribed to the Google Groups
"doctrine-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/doctrine-user.
For more options, visit https://groups.google.com/d/optout.
