OneToOneField behavior doesn't match docs

[Joseph Kocherhans]

The current trunk and magic-removal docs say this about OneToOneField:

* No ``Place`` selection interface is displayed on ``Restaurant`` pages.
There will be one (and only one) ``Restaurant`` for each ``Place``.

* On the ``Restaurant`` change list, every ``Place`` -- whether it has an
associated ``Restaurant`` or not -- will be displayed. Adding a
``Restaurant`` to a ``Place`` just means filling out the required
``Restaurant`` fields.

Neither of the above is currently true for magic-removal *or* the
trunk, although I remember it working that way a loooong time ago. Is
this still the expected behavior? I don't recall seeing any discussion
about it, and I can't find anything about the issue.

Here's what currently happens:

trunk: An html select element is displayed for OneToOneField
m-r: An html input type=text element is for OneToOneField, but it's
value attribute is empty when the change form is displayed.

Also, if you change OneToOneField in the admin system and save it, the
change won't be saved to the database. The manupulator overwrites the
id from the form with the id from the view (the id paramater taken
from the url). This is perfectly reasonable behavior if the OneToOne
field isn't displayed, or is displayed as read-only. As is, it's
confusing as hell.

Only existing Restaurants are listed for both trunk and m-r. Places
w/o Restaurants aren't listed at all.

I can probably fix this sometime this week, but I'm not going to
mandate what "fixing" actually means in this case. Thoughts?

I've opened ticket #1681 related to this.
http://code.djangoproject.com/ticket/1681

Joseph

[jkoch...@gmail.com]

Joseph Kocherhans wrote:
> The current trunk and magic-removal docs say this about OneToOneField:

[snip]

No feedback, so I've commited a patch. OneToOneField now behaves like
ForeignKey for adding objects in the admin system, and is displayed as
a read only field for the change form. Here's the ticket again.

http://code.djangoproject.com/ticket/1681

Joseph

[medhat]

Wouldn't moving this to the base class also affect ManyToManyField?

[Joseph Kocherhans]

Yep, it would. Good catch.

\ME smacks head for trying to avoid copy/pasting a method at the last minute.

Fixed in [2802]

Joseph

[Rudolph]

Nice fix. I found one problem. When a user "forgets" to set the
OneToOneField and saves the object, Django does not return a nice error
message but throws an exception because Django tries to insert a record
without the primary key set. Some kind of validation should be added to
prevent this. Shall I file a ticket?

The model used to get the exception:

from django.db import models
from django.contrib.auth.models import User

class Profile(models.Model):
user = models.OneToOneField(
User,
)
address = models.CharField(
'address',
maxlength = 150,
)
zipcode = models.CharField(
'zipcode',
maxlength = 50,
)
city = models.CharField(
'city',
maxlength = 100,
)
phone = models.CharField(
'phone',
maxlength = 25,
blank = True,
)
birthday = models.DateField(
'birthday',
)

class Admin:
pass

Cheers,
Rudolph

[Joseph Kocherhans]

On 5/3/06, Rudolph <rudolph...@gmail.com> wrote:
>
> Nice fix. I found one problem. When a user "forgets" to set the
> OneToOneField and saves the object, Django does not return a nice error
> message but throws an exception because Django tries to insert a record
> without the primary key set. Some kind of validation should be added to
> prevent this. Shall I file a ticket?

Please do. I'll look at it, but I might not get to it until the
weekend. If anyone else wants to have a look, feel free. Thanks for
the catch. I had a nagging feeling there were some corner cases I was
missing.

Joseph