Problem adding Askbot to existing project

edit

A easy fix is to change 0001_initial to define those 5 fields as "null=True".

I had the same problem. Executing the following before running ./manage.py migrate askbot fixed the silent fails for the rest to commit:

ALTER TABLE "auth_user"
ADD COLUMN "website" varchar(200) NOT NULL DEFAULT '',
ADD COLUMN "location" varchar(100) NOT NULL DEFAULT '',
ADD COLUMN "about" text NOT NULL DEFAULT '',
ADD COLUMN "real_name" varchar(100) NOT NULL DEFAULT '', 
ADD COLUMN "gravatar" varchar(32) NOT NULL DEFAULT '';

Olle, it seems that first migration of askbot possibly did not work.

Type python manage.py migrate --list - what do you see?

Also you could log in to the database and see what the table auth_user looks like.

In your case I'd start over and try running just migration 1 with command:

python manage.py migrate askbot 0001

Inspect the output and the database structure after the migration, if you find errors, we'll try to fix them.

I restored my database (PostgreSQL) and started over with "python manage.py migrate askbot 0001". This is the output:

relation "askbot_badgedata" does not exist
LINE 1: ..."."slug", "askbot_badgedata"."awarded_count" FROM "askbot_ba...
                                                             ^
 - Soft matched migration 0001 to 0001_initial.
Running migrations for askbot:
 - Migrating forwards to 0001_initial.
 > askbot:0001_initial

I didn't notice the badge_data error before.

This is what auth_users looks like before migration 0001:

id serial NOT NULL,
  username character varying(30) NOT NULL,
  first_name character varying(30) NOT NULL,
  last_name character varying(30) NOT NULL,
  email character varying(75) NOT NULL,
  password character varying(128) NOT NULL,
  is_staff boolean NOT NULL,
  is_active boolean NOT NULL,
  is_superuser boolean NOT NULL,
  last_login timestamp with time zone NOT NULL,
  date_joined timestamp with time zone NOT NULL,
  CONSTRAINT auth_user_pkey PRIMARY KEY (id ),
  CONSTRAINT auth_user_username_key UNIQUE (username )

And this is how auth_users looks like after migration 0001:

  id serial NOT NULL,
  username character varying(30) NOT NULL,
  first_name character varying(30) NOT NULL,
  last_name character varying(30) NOT NULL,
  email character varying(75) NOT NULL,
  password character varying(128) NOT NULL,
  is_staff boolean NOT NULL,
  is_active boolean NOT NULL,
  is_superuser boolean NOT NULL,
  last_login timestamp with time zone NOT NULL,
  date_joined timestamp with time zone NOT NULL,
  hide_ignored_questions boolean NOT NULL,
  gold smallint NOT NULL,
  email_isvalid boolean NOT NULL,
  email_key character varying(32),
  date_of_birth date,
  reputation integer NOT NULL,
  bronze smallint NOT NULL,
  tag_filter_setting character varying(16) NOT NULL,
  last_seen timestamp with time zone NOT NULL,
  silver smallint NOT NULL,
  questions_per_page smallint NOT NULL,
  response_count integer NOT NULL,
  CONSTRAINT auth_user_pkey PRIMARY KEY (id ),
  CONSTRAINT auth_user_username_key UNIQUE (username ),
  CONSTRAINT auth_user_reputation_check CHECK (reputation >= 0)

I am encountering the same issue. My setup also failed at migration 0006. Here is what my auth_user looks like after migration 0005:

                                          Table "public.auth_user"
         Column         |           Type           |                       Modifiers
------------------------+--------------------------+--------------------------------------------------------
 id                     | integer                  | not null default nextval('auth_user_id_seq'::regclass)
 username               | character varying(30)    | not null
 first_name             | character varying(30)    | not null
 last_name              | character varying(30)    | not null
 email                  | character varying(75)    | not null
 password               | character varying(128)   | not null
 is_staff               | boolean                  | not null
 is_active              | boolean                  | not null
 is_superuser           | boolean                  | not null
 last_login             | timestamp with time zone | not null
 date_joined            | timestamp with time zone | not null
 hide_ignored_questions | boolean                  | not null
 gold                   | smallint                 | not null
 email_isvalid          | boolean                  | not null
 email_key              | character varying(32)    |
 date_of_birth          | date                     |
 reputation             | integer                  | not null
 bronze                 | smallint                 | not null
 tag_filter_setting     | character varying(16)    | not null
 last_seen              | timestamp with time zone | not null
 silver                 | smallint                 | not null
 questions_per_page     | smallint                 | not null
 response_count         | integer                  | not null

So, quite a few fields missing (website, about, gravatar)

I took a look at the initial migration - I guess safe_add_column failed silently and continued to the next column.

Edit: I got it to work after manually adding missing columns. I had to add about 7-8 of them each time 'migrate' reached an error. Also had to drop a few tables that were being added multiple times. Isn't this exactly what south is supposed to prevent? Weird.

btw I'm using Django 1.3.1 and PostgreSQL 8.4.11 and integration with an existing project, existing users, and existing auth system (django-allauth).