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

[Eric Van Dewoestine <ervandew@…>]

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')

[Eric Van Dewoestine <ervandew@…>]

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

[Russell Keith-Magee]

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.

[Eric Van Dewoestine <ervandew@…>]

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.