Database error: relation does not exist, when using Postgresql

Issue #1402 new
Paul Walsh created an issue

django.db.utils.DatabaseError: relation "contact_organization" does not exist

The same project syncs fine with sqlite and MySQL, but throws errors with Postgresql.

I read older tickets, but they indicate that this problem was fixed. Its seems not.

Is there any known fix I can apply to keep moving now? I am using the latest code base from bitbucket.

Comments (4)

  1. Hynek Cernoch

    The most important is to use recent version of django-livesettings what was not clear from your report.

    I can not reproduce the problem. In general it is important to be reported: and Django versions, use of South yes/no, very simple/complicated code, db driver postgresql_psycopg2 (not the old postgresql deprecated) and finally to send a traceback

  2. Hynek Cernoch

    Please start communicating, preferably by sending the traceback, otherwise I can not do anything with your report. The solution, that I find, may be easy.

  3. Paul Walsh reporter

    Hi,

    Terribly sorry for the delayed response.

    I investigated further today, and the problem is not due to Satchmo as such, but, when syncdb-ing apps in which we subclass Product and ProductManager.

    I get around this by syncing without those apps, then another sync with them.

    I am not sure if you would consider this a bug or not - subclassing Product in a project app throws this error when trying to sync that app in postgresql.

    Thanks.

  4. Hynek Cernoch

    What you wrote would be a serious problem, but I can not reproduce it by simple subclassing the model Product. I tried it with both South enabled and disabled. (because South influences syncdb.)

    I can think of following scenario of your problem: The constructor of some db model tries database access (usually it is an simple select by livesettings), it fails the because the reqired table does not exist, but the message is silently sucked by some exception handling. The postgres transaction is in a failed state after this failed command and postgres does not do anything (creating tables) until rollback or closed connection. But the rollback is also not a solution because it cancels all previously created tables. Yes, temporary disabling the "wild" model is the last resort. I recommend to solve it because one day it can be not easy for you to find an easy solution after you have more such dependencies.

    Use this temporary patch for examining the problem: (it adds error logging to postgres driver)

    --- a/db/backends/postgresql_psycopg2/base.py
    +++ b/db/backends/postgresql_psycopg2/base.py
    @@ -45,6 +45,8 @@
             except Database.IntegrityError, e:
                 raise utils.IntegrityError, utils.IntegrityError(*tuple(e)), sys.exc_info()[2]
             except Database.DatabaseError, e:
    +            import traceback
    +            log.error("Database error %s:\n%s" % (e, traceback.format_exc()
                 raise utils.DatabaseError, utils.DatabaseError(*tuple(e)), sys.exc_info()[2]
    
         def executemany(self, query, args):
    

    The first db error is the important traceback. You will see what your code in the traceback is the last in long chain before call for premature db access. That caused it.

    The only solution is do not to touch other tables from model class definition or from its __init__ (e.g. by setting default value or choises for something = SomeField(... choices=some_func()) this way: (example from satchmo_utils.iterchoices)

    def some_func():
        command = introspect_management_command()
        if not command in ('syncdb', 'test'):
            ... do what you did want ...
        else:
            ... return some stub 
    

    Send the traceback please. Maybe we can prevent it. Subclassing Product is very usual why people can like Satchmo.

  5. Log in to comment