Extending the checks for related-name clashes

[Shai Berger]

Hi all,

When you define a related field on a model -- a ForeignKey etc -- it
usually adds its related-name as a backwards-accessor on the related
model. These related names are checked for clashes against other fields
and other related-names. But they are not checked for clashes against
other attributes of the remote model, like methods and properties.

A clash with another field (or accessor) is considered an error. I
think a clash with a property should be at least a warning. Currently
it is accepted silently (and AFAICT, the related-name takes
precedence, that is, the property is effectively deleted).

Does anybody think this is the desired behavior?

Thanks,
Shai.

[Adam Johnson]

I think it would be acceptable to make related name clashes a check Error. I'm guessing you couldn't find any justification for why the check doesn't currently do this?

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200906133146.4449641c.shai%40platonix.com.

--

Adam

[Shai Berger]

On Sun, 6 Sep 2020 12:01:34 +0100
Adam Johnson <m...@adamj.eu> wrote:

> I think it would be acceptable to make related name clashes a check
> Error. I'm guessing you couldn't find any justification for why the
> check doesn't currently do this?
>

I didn't find any, though I didn't look too hard.

On the other hand, I found that the behavior changes depending on the
target model being a proxy model (or rather, on the model defining the
property being a proxy model).

That is, with

class A(models.Model):
@property
def related(self):
return 15


class B(models.Model):
a = models.ForeignKey(A, related_name='related',
on_delete=models.CASCADE)


class C(A):
class Meta:
proxy = True

@property
def pro_related(self):
return 17


class D(models.Model):
c = models.ForeignKey(C, related_name='pro_related',
on_delete=models.CASCADE)


For instances a and c of A and C respectively,
a.related is a RelatedManager
c.pro_related is 17

This happens because reverse-accessors are promoted to the concrete
model -- the accessor attribute is set on A, which means it overrides
whatever was defined on A, but can be overridden by A's subclasses.

I believe the technical term of this is "a mess".

Shai.

[Adam Johnson]

I believe the technical term of this is "a mess".

Looks like it!

I can't think of any reason why this inconsistency would be desirable. Adding more checks is normally fine since they can be disabled by users who want/rely on the behaviour.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200906155425.17c1d7f8.shai%40platonix.com.

--

Adam