Modify

Ticket #924 (closed defect: duplicate)

Opened 3 years ago

Last modified 3 years ago

Migration requires committing by hand

Reported by: jacob@… Owned by: andrew
Priority: minor Milestone:
Component: migrations Version: 0.7.3
Keywords: Cc:

Description

This migration:

# encoding: utf-8
from south.db import dbs
from south.v2 import SchemaMigration

#
# Trac uses composite primary keys, which Django doesn't understand.
# These views fix that, for certain values of "fix."
#

class Migration(SchemaMigration):
    def forwards(self, orm):
        db = dbs['trac']
        db.execute('''CREATE VIEW "attachment_django_view" AS
            SELECT "type" || '.' || "id" || '.' || "filename" AS "django_id", *
            FROM attachment;''')
        db.execute('''CREATE VIEW "wiki_django_view" AS
            SELECT "name" || '.' || "version" AS "django_id", *
            FROM wiki;''')

    def backwards(self, orm):
        db = dbs['trac']
        db.execute('DROP VIEW attachment_django_view;')
        db.execute('DROP VIEW wiki_django_view;')

Doesn't actually get applied against PostgreSQL 9.0. The migration runs cleanly, but the views I expect to be created aren't:

$ ./manage.py migrate trac --list

 trac
  ( ) 0001_initial

$ ./manage.py dbshell --database=trac
code.djangoproject=# \dv
No relations found.

$ ./manage.py migrate trac
Running migrations for trac:
 - Migrating forwards to 0001_initial.
 > trac:0001_initial
 - Loading initial data for trac.
No fixtures found.

$ ./manage.py migrate trac --list

 trac
  (*) 0001_initial

$ ./manage.py dbshell --database=trac
code.djangoproject=# \dv
No relations found.

Here's what PostgreSQL logs:

LOG:  duration: 0.208 ms  statement: SET DATESTYLE TO 'ISO'
LOG:  duration: 0.117 ms  statement: SHOW client_encoding
LOG:  duration: 0.028 ms  statement: SHOW default_transaction_isolation
LOG:  duration: 0.109 ms  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
LOG:  duration: 0.698 ms  statement: SET TIME ZONE E'America/Chicago'
LOG:  duration: 0.433 ms  statement: SELECT version()
LOG:  duration: 0.996 ms  statement: SELECT "south_migrationhistory"."id", "south_migrationhistory"."app_name", "south_migrationhistory"."migration", "south_migrationhistory"."applied" FROM "south_migrationhistory" WHERE "south_migrationhistory"."applied" IS NOT NULL
LOG:  duration: 0.062 ms  statement: COMMIT
LOG:  duration: 0.231 ms  statement: SET DATESTYLE TO 'ISO'
LOG:  duration: 1.308 ms  statement: SHOW client_encoding
LOG:  duration: 0.129 ms  statement: SHOW default_transaction_isolation
LOG:  duration: 0.072 ms  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
LOG:  duration: 0.637 ms  statement: SET TIME ZONE E'America/Chicago'
LOG:  duration: 66.821 ms  statement: CREATE VIEW "attachment_django_view" AS
	            SELECT "type" || '.' || "id" || '.' || "filename" AS "django_id", *
	            FROM attachment;
LOG:  duration: 7.447 ms  statement: CREATE VIEW "wiki_django_view" AS
	            SELECT "name" || '.' || "version" AS "django_id", *
	            FROM wiki;
LOG:  duration: 0.062 ms  statement: BEGIN; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
LOG:  duration: 1.276 ms  statement: SELECT "south_migrationhistory"."id", "south_migrationhistory"."app_name", "south_migrationhistory"."migration", "south_migrationhistory"."applied" FROM "south_migrationhistory" WHERE ("south_migrationhistory"."app_name" = E'trac'  AND "south_migrationhistory"."migration" = E'0001_initial' )
LOG:  duration: 2.740 ms  statement: INSERT INTO "south_migrationhistory" ("app_name", "migration", "applied") VALUES (E'trac', E'0001_initial', E'2011-09-15 21:30:24.058881')
LOG:  duration: 7.093 ms  statement: SELECT CURRVAL(pg_get_serial_sequence('"south_migrationhistory"','id'))
LOG:  duration: 2.202 ms  statement: COMMIT
LOG:  unexpected EOF on client connection

This can be fixed by manually adding db.execute('COMMIT') to the forwards/backwards migrations, which leads me to suspect that South isn't properly committing transactions on secondary databases?

I also tried db.commit_transaction(), but that raises an error about not being in transaction management. So maybe this is actually a Django bug? I'm running 1.3.1 if that matters.

Attachments

Change History

comment:1 Changed 3 years ago by andrew

Ah, yes, this is a side-effect of South's lack of proper multi-db support - it wraps migrations on the main database in transactions, but nothing else (as, really, the migrations for another database should be stored and tracked in that database somehow, so this is an open problem).

I'd rather close this and take it under the umbrella of "extended multi-db support" (ticket #370), if you agree - it's just an artifact of that.

The error about transaction management is just that Django won't put the database connection in transaction-managed mode by default.

comment:2 Changed 3 years ago by jacob@…

Ah, OK -- that makes sense. Yeah, considering this a subset of #370 seems right by me.

comment:3 Changed 3 years ago by andrew

  • Status changed from new to closed
  • Resolution set to duplicate

Excellent. Closing as duplicate of #370.

View

Add a comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.