id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 17530,Fixture loading with deferred constraints broken for Postgres for fixtures from multiple dirs,Luke Plant,nobody,"If you call 'loaddata' such that fixtures are loaded from multiple directories, and these fixtures depend on each other, with Postgres you can get a constraint exception, e.g. {{{ Problem installing fixture '/home/luke/devel/mezzanine/mezzanine/forms/fixtures/mezzanine.json': Traceback (most recent call last): File ""/home/luke/devel/django/trunk/django/core/management/commands/loaddata.py"", line 207, in handle connection.check_constraints(table_names=table_names) File ""/home/luke/devel/django/trunk/django/db/backends/postgresql_psycopg2/base.py"", line 129, in check_constraints self.cursor().execute('SET CONSTRAINTS ALL IMMEDIATE') File ""/home/luke/devel/django/trunk/django/db/backends/util.py"", line 36, in execute return self.cursor.execute(sql, params) File ""/home/luke/devel/django/trunk/django/db/backends/postgresql_psycopg2/base.py"", line 52, in execute return self.cursor.execute(query, args) IntegrityError: insert or update on table ""forms_form"" violates foreign key constraint ""page_ptr_id_refs_id_1d5610fd"" DETAIL: Key (page_ptr_id)=(3) is not present in table ""pages_page"". }}} This is contrary to the docs, which says that although the order in which fixtures are created is undefined, it doesn't matter and forward references will work because the constraints are only checked at the end. The bug is obvious from eyeballing the code: the call to check_constraints occurs inside the 'for fixture_dir in fixture_dirs' iteration, instead of outside it. This is a regression since 1.3.X, almost certainly from [16590], and is a release blocker. ",Bug,closed,Core (Management commands),1.3,Release blocker,fixed,,L.Plant.98@…,Ready for checkin,1,0,0,0,0,0