Django builds a list of all the objects that are foreign keyed to the
one you are deleting and deletes those first, so it bypasses any ON
DELETE clauses. I assume this is what you're seeing.
I'm preparing to propose a patch that will add ON DELETE and ON UPDATE
support to Django (so that you can specify whether to CASCADE, RESTRICT,
etc., in the ForeignKey definition directly in the Django model model),
but it probably won't be accepted before the Django 1.0 release (and
maybe not after--who knows). In the meantime, you can disable this
behavior by finding the django.db.models.base._collect_sub_objects
function and modifying it as follows:
> def _collect_sub_objects(self, seen_objs):
> """
> Recursively populates seen_objs with all objects related to this object.
> When done, seen_objs will be in the format:
> {model_class: {pk_val: obj, pk_val: obj, ...},
> model_class: {pk_val: obj, pk_val: obj, ...}, ...}
> """
> pk_val = self._get_pk_val()
> if pk_val in seen_objs.setdefault(self.__class__, {}):
> return
> seen_objs.setdefault(self.__class__, {})[pk_val] = self
>
> return #INSERT THIS RETURN TO DISABLE DJANGO'S PSEUDO "ON CASCADE DELETE"
>
> for related in self._meta.get_all_related_objects():
> rel_opts_name = related.get_accessor_name()
> if isinstance(related.field.rel, OneToOneRel):
> try:
> sub_obj = getattr(self, rel_opts_name)
> except ObjectDoesNotExist:
> pass
> else:
> sub_obj._collect_sub_objects(seen_objs)
> else:
> for sub_obj in getattr(self, rel_opts_name).all():
> sub_obj._collect_sub_objects(seen_objs)
Mike
Luke Plant wrote:
> Hi all,
>
> I'm trying to pin down what I think is a bug in Model.delete(), but
> I'm encountering bizarre behaviour with my tests that I can't
> reproduce in normal circumstances. In particular, it is as if
> foreign key constraint checking has been turned off.
>
> The attached patch adds tests that can be run with:
>
> ./tests/runtests.py --settings=your.settings.module delete
>
> Currently the tests pass, but they shouldn't -- the DELETE statement
> should produce an IntegrityError or OperationalError (or, if 'ON
> DELETE CASCADE' was set then the subsequent queries should return
> nothing). If I try similar things outside the test harness, I get
> the exceptions I expect.
>
> I'm testing this using a Postgres database, I've also tested with
> sqlite and get the same thing, I haven't tested with MySQL.
>
> Can anyone else confirm what I'm seeing? It is very bizarre. Does
> anyone know if the test harness does something unusual with
> constraints?
>
> Cheers,
>
> Luke
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
