Джанго на юг от MySQL до postgresql - PullRequest
Новая
       7

Джанго на юг от MySQL до postgresql

1 голос
/ 02 сентября 2011

Я впервые начал использовать MySQL в одном из своих приложений, и теперь я думаю о переходе с MySQL на PostgreSQL.

У меня установлен South для миграции.Когда я настраивал новую БД в postgres, я успешно синхронизировал свои приложения и полностью остановился в одной из моих последних миграций. 

> project:0056_auto__chg_field_project_project_length
Traceback (most recent call last):
  File "./manage.py", line 11, in <module>
    execute_manager(settings)
  File "/Users/ApPeL/.virtualenvs/fundedbyme.com/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "/Users/ApPeL/.virtualenvs/fundedbyme.com/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/ApPeL/.virtualenvs/fundedbyme.com/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Users/ApPeL/.virtualenvs/fundedbyme.com/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
    output = self.handle(*args, **options)
  File "/Library/Python/2.7/site-packages/south/management/commands/migrate.py", line 105, in handle
    ignore_ghosts = ignore_ghosts,
  File "/Library/Python/2.7/site-packages/south/migration/__init__.py", line 191, in migrate_app
    success = migrator.migrate_many(target, workplan, database)
  File "/Library/Python/2.7/site-packages/south/migration/migrators.py", line 221, in migrate_many
    result = migrator.__class__.migrate_many(migrator, target, migrations, database)
  File "/Library/Python/2.7/site-packages/south/migration/migrators.py", line 292, in migrate_many
    result = self.migrate(migration, database)
  File "/Library/Python/2.7/site-packages/south/migration/migrators.py", line 125, in migrate
    result = self.run(migration)
  File "/Library/Python/2.7/site-packages/south/migration/migrators.py", line 99, in run
    return self.run_migration(migration)
  File "/Library/Python/2.7/site-packages/south/migration/migrators.py", line 81, in run_migration
    migration_function()
  File "/Library/Python/2.7/site-packages/south/migration/migrators.py", line 57, in <lambda>
    return (lambda: direction(orm))
  File "/Users/ApPeL/Sites/Django/fundedbyme/project/migrations/0056_auto__chg_field_project_project_length.py", line 12, in forwards
    db.alter_column('project_project', 'project_length', self.gf('django.db.models.fields.IntegerField')())
  File "/Library/Python/2.7/site-packages/south/db/generic.py", line 382, in alter_column
    flatten(values),
  File "/Library/Python/2.7/site-packages/south/db/generic.py", line 150, in execute
    cursor.execute(sql, params)
  File "/Users/ApPeL/.virtualenvs/fundedbyme.com/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in execute
    return self.cursor.execute(query, args)
django.db.utils.DatabaseError: column "project_length" cannot be cast to type integer

Мне интересно, есть ли какое-то решение для этого?

Ответы [ 2 ]

2 голосов
/ 03 сентября 2011

Ваша текущая миграция работает следующим образом:

  1. Изменить столбец "project_length" на другой тип.

Он сломан, потому что вы делаете alter, который не поддерживается PostgreSQL.

Вы должны исправить вашу миграцию. Вы можете изменить его на следующую миграцию (это будет работать, но, вероятно, это будет проще):

  1. Создайте еще один столбец project_length_tmp с типом, который вы хотите иметь для project_length, и некоторым значением по умолчанию.
  2. Выполнить миграцию данных из столбца project_length в project_lenght_tmp (см. Миграцию данных в южных документах).
  3. Удалить столбец project_length.
  4. Переименовать столбец project_length_tmp в project_length.

Вроде сложная миграция, но у нее есть две сильные стороны: 1. Он будет работать на всех базах данных. 2. Он совместим с вашей старой миграцией, так что вы можете просто переопределить старую миграцию (изменить файл), и все будет в порядке.

Подход 2

Еще один подход к вашей проблеме - просто удалить все миграции и начать с нуля. Если у вас есть только одно развертывание вашего проекта, он будет работать нормально для вас.

0 голосов
/ 03 сентября 2011

Вы не предоставляете никаких подробностей о выполняемом SQL, но кажется маловероятным, что это сбой ALTER TYPE - при условии, что SQL правильный. 

=> CREATE TABLE t (c_text text, c_date date, c_datearray date[]);
CREATE TABLE
=> INSERT INTO t VALUES ('abc','2011-01-02',ARRAY['2011-01-02'::date,'2011-02-03'::date]);
INSERT 0 1
=> ALTER TABLE t ALTER COLUMN c_text TYPE integer USING (length(c_text));
ALTER TABLE
=> ALTER TABLE t ALTER COLUMN c_date TYPE integer USING (c_date - '2001-01-01');
ALTER TABLE
=> ALTER TABLE t ALTER COLUMN c_datearray TYPE integer USING (array_upper(c_datearray, 1));
ALTER TABLE
=> SELECT * FROM t;
 c_text | c_date | c_datearray 
--------+--------+-------------
      3 |   3653 |           2
(1 row)

Не так много вы не можете сделать,Я предполагаю, что это неправильный SQL, генерируемый из этого модуля Django, который вы используете.

...