Abstract model class specifies foreign key – MySQL doesn't have it.

[Mike Robinson]

The abstract class is:

class AbstractForumProfile(models.Model):
    """
    Represents the profile associated with each forum user.
    """
    user = models.OneToOneField(
        settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name='forum_profile',
        verbose_name=_('User'))

    # The user's avatar.
    avatar = ExtendedImageField(
        verbose_name=_('Avatar'), null=True, blank=True,
        upload_to=machina_settings.PROFILE_AVATAR_UPLOAD_TO,
        **machina_settings.DEFAULT_AVATAR_SETTINGS)

    # The user's signature.
    signature = MarkupTextField(
        verbose_name=_('Signature'), blank=True, null=True,
        validators=[validators.NullableMaxLengthValidator(
            machina_settings.PROFILE_SIGNATURE_MAX_LENGTH)])

    # The amount of posts the user has posted (only approved posts are considered here).
    posts_count = models.PositiveIntegerField(verbose_name=_('Total posts'), blank=True, default=0)

The derived class is:

class ForumProfile(AbstractForumProfile):
    auto_subscribe_topics = models.BooleanField(
        verbose_name='Automatically subscribe to topics you create.',
        default=False)
                
    notify_subscribed_topics = models.BooleanField(
        verbose_name='Receive an email notification on new replies to subscribed topics.',
        default=False)

but the resulting MySQL syntax (which does not show ON DELETE CASCADE on the FOREIGN KEY constraint) is:

CREATE TABLE `forum_member_forumprofile` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `avatar` varchar(100) DEFAULT NULL,
  `signature` longtext,
  `posts_count` int(10) unsigned NOT NULL,
  `_signature_rendered` longtext,
  `user_id` int(11) NOT NULL,
  `auto_subscribe_topics` tinyint(1) NOT NULL DEFAULT '0',
  `notify_subscribed_topics` tinyint(1) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `user_id` (`user_id`),
  CONSTRAINT `forum_member_forumprofile_user_id_9d6b9b6b_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=53 DEFAULT CHARSET=latin1;

[Mariusz Felisiak]

Django doesn't use ON DELETE CASCADE it emulates its behavior (see ​documentation).

[Mike Robinson]

Reopening this, because something is broken:

django.db.utils.IntegrityError: (1451, 'Cannot delete or update a parent row: a foreign key constraint fails (`gga$GGA`.`forum_member_forumprofile`, CONSTRAINT `forum_member_forumprofile_user_id_9d6b9b6b_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`))')

If Django was supposed to do the cascading deletes by its own logic, it didn't.

[Mariusz Felisiak]

I cannot reproduce this issue with provided models, everything works properly for me. You could provided a sample project but due to the fact that this behavior is tested I don't think that there it is an issue in Django. I would rather use one of support channels.

[Mike Robinson]

I will attempt to produce the simplest possible test case and report back. However, this issue occurs within the Django Admin when attempting to delete a User. The table n question is the user-profile as shown above. That should be "pure Django code."

But also: I think that I am seeing other instances of this in the same application – other cases involving foreign keys and deletion. (Delete posts, etc.) Yes, it is possible that this is some obscure application (model) issue and I will indeed pursue this to try to help resolve the problem. But I am suspicious, specifically, of some issue in OneToOneField.

I realize, however, that "you've got to see it to fix it." Stay tuned. Thanks.

[Mike Robinson]

Changed status to "worksforme" since there *is* something wrong here but "it's not going to be quite that easy, as it turns out" to reproduce it. So it goes.