Database Error on Dotcloud, Postgres Django

Question

I'm deploying my django app with Dotcloud. I use Postgres as DB.

I had a new model to my app, and I wanted to flush and syncdb the db. Everything works find when I do it. My new model, named 'Competition' appears in my admin.

The problem is that an other model, Match, has a ForeignKey with the model Competition. And when I go to 'Matchs' in my admin, I get this error:

     DatabaseError at /admin/myproject/match/
     column myproject_match.competition_id does not exist
     LINE 1: ...team_challenger_id", "sportdub_match"."sport_id", "sportdub_...

Any idea on why the syncdb didn't make it work find?

Thank you for your help.

EDIT: My two models

     class Competition(models.Model):
       name = models.CharField(max_length=256)
       comp_pic = models.ImageField(upload_to="comp_pics/")

       def __unicode__(self):
           return self.name


     class Match(models.Model):
        team_host = models.ForeignKey(Team, related_name='host_matches')
        team_challenger = models.ForeignKey(Team, related_name= 'challenger_matches')
        sport = models.ForeignKey(Sport)
        competition = models.ForeignKey(Competition)

Answer 1

manage.py syncdb will only create missing tables. If a table already exists, but with an invalid definition, it will not be updated. This is very probably the problem that you are experiencing.

There are at least three ways to solve the problem.

1. The easy way: use manage.py reset to effectively drop+recreate all the tables. Easy, but of course you will lose the data.
2. The lazy way: install django_extensions and use manage.py sqldiff. It will show you the difference between the current structure of the database, and the expected structure. sqldiff will nicely show you SQL statements which can update the existing database to conform with your models. You can then execute those statements in a SQL shell.
3. The clean way: use a migrations framework like south to handle database schema updates. Of course, if you are early in the development, this is overkill (you do not want to write database migrations each time you add/change/remove a field while you're doing local development!) but if your project will have a longer life span, I definitely recommend checking out south.