ForeignKey's attname is counter-intuitive when referencing to a field not named 'id'

[Alexander Schepanovski]

class SomeModel(model.Model):
    region = models.ForeignKey(Region, to_field='code')

sm = SomeModel()
sm.region # works
sm.region_code # AttributeError, currently
sm.region_id # works, but evaluates to sm.region.code

Also, currently we have:

CREATE TABLE "app_somemodel" (
    ...
    "region_id" integer NOT NULL REFERENCES "geo_region" ("code") DEFERRABLE INITIALLY DEFERRED,
    ...
);

which also looks strange.

[Łukasz Rekucki]

First, this change is *very* backwards incompatible, as it would require to migrate any db schema that has a foreign key.

Second, I hope that someday Django will support multi-column (primary) keys and it probably won't look so good then.

[anonymous]

Not *very* backward incompatable since references to fields named "id" (most primary keys) won't trigger changes.
Still it is backward incompatable, promoting to design decision needed.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

I don't think there's much value in this change at this point in the history of Django.