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
