related_name='+' ignored in ManyToManyField validation

[Fredde]

According to the documentation (​http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name) setting related_name='+' to any relation field should prevent django from creating a related field. This also seems to be the case in the contribute_to_related_class functions. However the validation of ManyToMany fields ignors this and gives an error message anyway.

To reproduce:

class A(models.Model):
        pass

class B(models.Model):
        # This works
        fk1 = models.ForeignKey(A, related_name = '+')
        fk2 = models.ForeignKey(A, related_name = '+')
        
        # This gives a "Accessor for m2m field 'm2m1' clashes with related m2m field 'A.+'" error
        m2m1 = models.ManyToManyField(A, related_name = '+')
        m2m2 = models.ManyToManyField(A, related_name = '+')

The attached patch will make the validator check f.rel.is_hidden() before doing any further validation of related field names.

[Aymeric Augustin]

Confirmed with trunk.

[Jann Kleen]

I applied this patch but ran into some problems.

The m2m-insert worked as expected, but whenever executing .all(), the orm would create a sql query for the wrong table...

The problem was fixed when i gave all fields unique related_names again...

Model structure:

class A(models.Model):
    tags = models.ManyToManyField('tag', related_name='+')
    class Meta:
        abstract = True

class B(A):
    pass

class C(A):
    pass

Queries:

>>>b.tags.add(tag)
>>>b.tags.all()
[]

The .all() produces a SQL query which looks roughly like that: (i.e. the orm picks the wrong m2m-table for some reason)

SELECT * FROM "foo_tag" INNER JOIN "foo_c_tags" ON ("foo_tag"."id" = "foo_c_tags"."tag_id") WHERE "foo_c_tags"."c_id" = 1;

[Clay McClure]

Patch (with test) against 1.4rc1

[Clay McClure]

This continues to be a problem in 1.4rc1. The attached patch fixes the reported model validation problem. If there is a problem in the ORM, that could be tracked in a separate ticket.

[sean@…]

I created a ticket for the ORM issue mentioned above: #18595
I think the work-around I mentioned in that ticket will work here as well.

Basically create a unique related_name value ending with '+' and it may avoid both issues.

[Aymeric Augustin]

#18621 was a duplicate. I had forgotten about this ticket. I think it's a documentation issue. related_name must be unique and can end with '+' if you don't want the reverse relation to be created (although I don't know in which circumstances you wouldn't want to -- I you don't use it it doesn't hurt!)

[Claude Paroz]

Explain related_name ended with +

[Claude Paroz]

Attached a patch with updated documentation about related_name. Please check the wording.

[anonymous]

The statement that related_name has to be unique within a model is not true for the following cases:

• The relation fields refers till different models
• The related_name is "+" for a ForeignKey field

[Anssi Kääriäinen]

I don't think the patch is correct.

To me it seems the related_name must be unique in the related model, not in the originating model. And, as the '+' implies the related name is hidden in the related model, I don't see why it should be unique in this case even in the related model. It doesn't need to be unique, as it shouldn't exists at all. Maybe this is not a documentation issue after all?

[Claude Paroz]

Fixed docs as of comment:7

[Tim Graham <timograham@…>]

In [b496be331c19f41bee3a8f6c79de0722f91d6662]:

Fixed #15932 - Documented how to supress multiple reverse relations to the same model.

Thanks Claude Paroz for the patch.

[Tim Graham <timograham@…>]

In [1d280026c3797a23075739f28bb238972afad317]:

[1.4.X] Fixed #15932 - Documented how to supress multiple reverse relations to the same model.

Thanks Claude Paroz for the patch.

Backport of b496be331c from master

[Loic Bistuer <loic.bistuer@…>]

In 82a58ce5b67e0b79fa0efbad72e21d9d1be25ceb:

Fixed #21491 -- Removed documented workaround for a known issue.

The issue was that two M2M hidden reverse managers
(related_name ending with a '+') could clash with each other.

Refs #21375 and #15932. Thanks Baptiste.