Opened 7 years ago

Closed 5 years ago

#18668 closed New feature (fixed)

Make related_query_name more configurable

Reported by: zmsmith Owned by: nobody
Component: Database layer (models, ORM) Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


Using related_name for accessor_name and related_query_name makes it difficult it mimic django's default functionality with overridden attribute names.

For example, if I have a model Foo with a ForeignKey to Bar, but I want Bar to interact with Foo as though it's a model named Fizz there's no way to allow Bar to have an attribute called fizz_set and query against the field fizz.

I believe this could be implemented easily and be backwards compatible by giving ForeignKey and ManyToManyField additional key word argument related_query_name that would be passed down to rel_class. Then get_query_name could just check for the existence of this value before returning either related_name or opts.object_name.lower() as it currently does.

Are there any reasons not to do this? I couldn't find any prior discussion in Trac.

Change History (4)

comment:1 Changed 6 years ago by Aymeric Augustin

Triage Stage: UnreviewedAccepted

It took me quite some time to understand the problem described here, but I think it's valid.

I'll rephrase it to ensure we're talking about the same thing, and for the benefit of other contributors.

The OP's description translates to the following models:

from django.db import models

class Bar(models.Model):

class Foo(models.Model):
    name = models.CharField(max_length=100)
    bar = models.ForeignKey(Bar)

With these definitions, you can do:


Now, if you add related_name='fizz_set' to the ForeignKey declaration, you can do:

#                      ^^^^-- ugly!

And if you add related_name='fizz' it doesn't improve the situation:

#   ^^^^-- ugly!

comment:3 Changed 6 years ago by Tim Graham

Patch needs improvement: set

Part of what's included in the PR above was committed in 99b467f272da91b8894dc90d793d8d2c40b78d8c and 12cb0df10f12e715bcaafbee4290c92d4ed6f111. It looks like the PR contains some things that weren't added (e.g. adding this on generic relations) but it needs to be updated to merge cleanly.

comment:4 Changed 5 years ago by loic84

Resolution: fixed
Status: newclosed

#22207 [b77f26313cddbfde20dcf2661e9bd35458c2d1bd] fixed the remaining case of generic relations.

Note: See TracTickets for help on using tickets.
Back to Top