Saturday, February 21, 2015¶
235 stale controllables¶
I am investigating what to do with the 235 stale controllables in Eupen.
lino.modlib.contenttypes, I changed
StaleGenericRelatedByModel. They no longer detect only stale
owner fields of
Controllable rows but any stale
GenericForeignKey field in the database.
Added a new test module for testing this table:
Which made me discover that when I delete an object, Django does automatically delete any objects which have a GenericForeignKey pointing at it as well. Already in 1.6.
So theoretically I can remove my custom
Model.delete method which did exactly that.
I have been reinventing the wheel once more. And I am going to adapt
Lino to Django. Yes (sigh!), that’s the disadvantage of being a poor
One problem is that in Lino you can configure the cascading behaviour
allow_stale_generic_foreignkey. Okay, in
Django you can write a pre_delete signal.
Another problem is that in Lino you can inform the user and ask for confirmation before deleting them.
Another problem is that in Django this automatism happens only if the
object being deleted has a GenericRelation
field. Which is confirmed by Why won’t my GenericForeignKey cascade
OTOH this statement seems to be wrong: it happens also in my projects
which do not use any GenericRelation. As
Which means that
objects are currently not preserved if their master or object
pointer becomes stale. See #30 (Keep change records when
partner gets deleted). I must probably write a signal handler for
pre_delete. A minor problem, though. Clear nullable foreign keys
All this raises the question: How then did these stale generic pointers get into the database in Eupen? Okay, I can imagine that if some bug in some user code raises an exception at the right (i.e. the wrong) moment.
And last but not least:
how then can I artificially produce some stale GenericRelated objects for testing purposes?
how to clean up these?