Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#3103 closed enhancement (wontfix)

[patch]: Remove restriction on string name for relationship fields.

Reported by: Eric Van Dewoestine <ervandew@…> Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version: dev
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Patch based on development version 4051.

As described in the many-to-one relationships doc http://www.djangoproject.com/documentation/model_api/#many-to-one-relationships, django currently has the following restriction:

If you need to create a relationship on a model that has not yet been defined,
you can use the name of the model, rather than the model object itself:

...

Note, however, that you can only use strings to refer to models in the same
models.py file -- you cannot use a string to reference a model in a different
application, or to reference a model that has been imported from elsewhere.

The attached patch removes this restriction allowing one to do something like:

class Car(models.Model):
    manufacturer = models.ForeignKey('mysite.myotherapp.models.Manufacturer')

Attachments (1)

related.py.diff (423 bytes ) - added by Eric Van Dewoestine <ervandew@…> 18 years ago.

Download all attachments as: .zip

Change History (4)

by Eric Van Dewoestine <ervandew@…>, 18 years ago

Attachment: related.py.diff added

comment:1 by Eric Van Dewoestine <ervandew@…>, 18 years ago

note: patch is for file django/db/models/fields/related.py

comment:2 by Russell Keith-Magee, 18 years ago

Resolution: wontfix
Status: newclosed

The restriction on forward declared models is by design.

Forward declarations of a model in the same applicaiton is required because there might be circular dependencies between models. However, applications themselves should be self contained. Any dependencies on other applications should be relatively simple 'prerequisites' - for example, assuming that contrib.auth is installed.

If you have two applications that are co-dependent, it's a pretty good indication that you actually have 1 application, not two, and the two applications should be merged.

comment:3 by Eric Van Dewoestine <ervandew@…>, 18 years ago

I am actually using this patch in relation to another patch I made (which I have not submitted).

The dependent patch adds an alternative to the contrib.auth.User.get_profile that instead conditionaly adds a direct relationship to a settings defined profile model. This allows for running database queries across the auth user table onto the now joined profile:

Poll.objects.filter(userprofilemyfield='my value')

If the rejection of this patch is based solely on assumed 'best practices', should the django code be dictating this? Or does the added flexibilty for users out weight that?

I understand if you still don't want to apply the patch, but I don't see any inherent downside.

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