On 5/3/06, Rudolph <[EMAIL PROTECTED]> 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
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. Shal
On 5/1/06, medhat <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> > 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 addi
[EMAIL PROTECTED] wrote:
> 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 onl
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
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
