Question

I followed a bit the steps on Django User Profiles – Simple yet powerful.

Not quite the same because I am in the middle of developing the idea.
From this site I used in particular, also this line:

User.profile = property(lambda u:
UserProfile.objects.get_or_create(user=u)[0])

I was getting always an error message on creating the object, typically
“XX” may not be null. I solved part of the problems by playing with models
and (in my present case) sqliteman. Till I got the same
message on the id: “xxx.id may not be null”.

On the net I found a description of a possible solution which involved doing a reset
of the database, which I was not that happy to do. In particular because for the
different solutions, it might have involved the reset of the application db.

But because the UserProfile model was kinda new and till now empty,
I played with it on the DB directly and made an hand made drop of the table and
ask syncdb to rebuilt it. (kinda risky thought).

Now this is the diff of the sqlite dump:

294,298c290,294
< CREATE TABLE "myt_userdata" (
<     "id" integer NOT NULL PRIMARY KEY,
<     "user_id" integer NOT NULL UNIQUE REFERENCES "auth_user" ("id"),
<     "url" varchar(200),
<     "birthday" datetime
---
> CREATE TABLE myt_userdata (
>     "id" INTEGER NOT NULL,
>     "user_id" INTEGER NOT NULL,
>     "url" VARCHAR(200),
>     "birthday" DATETIME

Please note that both versions are generated by django. The “>” version was generated with a simple model definition which had indeed the connection with the user table via:

user = models.ForeignKey(User, unique=True)

The new “<” version has much more information and it is working.

My question:

Why Django complains about an myt_userdata.id may not be null?

The subsidiary question:

Does Django tries to relate to the underline db structure, how?
(for example the not NULL message comes from the model or from the DB?)

The additional question:

I have been a bit reluctant to the use south: Too complicated, additional modules
which I might have to care between devel and production and maybe not that easy
if I want to switch DB engine (I am using sqlite only at devel stage, I plan to move to
mysql).

Probably south might have worked in this case. Would it work? would you suggest its use
anyway?

Edited FIY:

This is my last model (the working one):

class UserData(models.Model):

    user = models.ForeignKey(User, unique=True)

    url = models.URLField("Website", blank=True, null=True)

    birthday = models.DateTimeField('Birthday', blank=True, null=True)

    def __unicode__(self):
        return self.user.username

User.profile = property(lambda u: UserData.objects.get_or_create(user=u,defaults={'birthday': '1970-01-01 00:00:00'})[0])

Answer 1

Why Django complains about an myt_userdata.id may not be null?

Because id is not a primary key and is not populated automatically though. Also, you don’t provide it on model creation, so DB does not know what to do.

Does Django tries to relate to the underline db structure, how? (for example the not NULL message comes from the model or from the DB?)

It’s an error from DB, not from Django.

You can use sql command to understan what exactly is executed on syncdb. Variant above seems to be correct table definition made from correct Django model, and I have no ide how have you got a variant below. Write a correct and clear model, and you’ll get correct and working table scheme after syncdb