I created a \'profile\' model (with a 1-to-1 relationship to the User model) as described on Extending the existing user model. The profile model has an optional many-to-one
The problem can be avoided by setting primary_key=True on the OneToOneField pointing at the User model, as you have figured out yourself.
The reason that this works seems to be rather simple.
When you try to create a model instance and set the pk manually before saving it, Django will try to find a record in the database with that pk and update it rather than blindly attempting to create a new one. If none exists, it creates the new record as expected.
When you set the OneToOneField as the primary key and Django Admin sets that field to the related User model's ID, that means the pk is already set and Django will attempt to find an existing record first.
This is what happens with the OneToOneField set as primary key:
User instance, with no id.User instance.
pk (in this case id) is not set, Django attempts to create a new record.id is set automatically by the database.post_save hook creates a new Profile instance for that User instance.Profile instance, with its user set to the user's id.Profile instance.
pk (in this case user) is already set, Django attempts to fetch an existing record with that pk.If you don't set the primary key explicitly, Django instead adds a field that uses the database's auto_increment functionality: the database sets the pk to the next largest value that doesn't exist. This means the field will actually be left blank unless you set it manually and Django will therefore always attempt to insert a new record, resulting in a conflict with the uniqueness-constraint on the OneToOneField.
This is what causes the original problem:
User instance, with no id.User instance, the post_save hook creating a new Profile instance as before.Profile instance, with no id (the automatically added pk field).Profile instance.
pk (in this case id) is not set, Django attempts to create a new record.user field.