[odb-users] is on_delete kinda useless or is it me?

[Boris Kolpackov]

NIkolai Marchenko <enmarantispam at gmail.com> writes:

> Whether it is attached to actual full pointer member or to a points_to id
> it will only delete the most derived data in the table of the class it is
> declared it. The earlier polymorphic table records are unaffected which
> means a lot of dead garbage is left in those.

Yes, on_delete is of limited use in case of polymorphic objects. The
"derived" tables have foreign keys referencing the (ultimate) "base"
table with the ON DELETE CASCADE semantics. So if the on_delete(cascade)
pointer member is in the (ultimate) base class, then the entire hierarchy
will always be cleaned up. But if it is in one of the derived classes,
then, yes, rows residing in other tables will not be automatically cleaned
up if it is deleted via the CASCADE semantics. I will clarify this in
the documentation.

I don't think we can easily fix this. The only way to make it work would
be to have bi-directional foreign keys going up and down the hierarchy,
which is a can of worms I don't think we should open.

The only workaround that I can think of is to use ON DELETE SET NULL
instead and handle such NULL'ed objects in the application (for example,
detect and ignore/cleanup).

> If so - what's the point?

You mean what is the point of on_delete(cascade)? Polymorphic objects are
a niche feature. Most ODB users don't need them. And in non-polymorphic
object models on_delete(cascade) works pretty well.