First time here? Check out the FAQ!

Revision history  [back]

Problem applying Migrations 24 and 25

arghhh
Trying to migrate from 0.6.17 to 0.6.48 - Straight environment - mysql backend

UPDATE: I have updated to the latest version, and migration 24 now works. However, 25 still fails.
I've decided to delve more deeply in this, and here is my findings:

There are some issues in the migration itself:

xxx> python manage.py migrate askbot
 Running migrations for askbot:
  - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
  > askbot:0025_transfer_flagged_items_to_activity
 - Migration 'askbot:0025_transfer_flagged_items_to_activity' is marked for no-dry-run.
  ! Error found during real run of migration! Aborting.
...
    File "...askbot/migrations/0025_transfer_flagged_items_to_activity.py", line 35, in forwards
      assert(activity.content_type==flag.content_type)
    File "...django/db/models/fields/related.py", line 244, in __get__
      raise self.field.rel.to.DoesNotExist

Issue 1:

Line 35: assert(activity.content_type==flag.content_type)

The tables activity and flagged_item don't have content_type field. They have "content_type_id" fields. Same with user vs. user_id, but that one doesn't complain.

Issue 2:
Once that was fixed, I ran into the assertion failure where content type is different!

Here is the entire flagged_item table:

mysql> select * from flagged_item;
+-----------+---------------------+----+-----------------+---------+
| object_id | flagged_at          | id | content_type_id | user_id |
|       166 | 2010-11-01 15:55:02 | 1  |              21 |      10 |
+-----------+---------------------+----+-----------------+---------+

mysql> select * from activity where object_id=166;
| is_audited | object_id | user_id | content_type_id | active_at     | id  | activity_type | question_id |
+--------------------------------------------------------------------------------------------------------+
|          0 |       166 |       3 |              26 | 2010-10-28 12:| 432 |             2 |         155 |
|          0 |       166 |       3 |              21 | 2010-10-28 16:| 458 |             1 |         166 |
+--------------------------------------------------------------------------------------------------------+

There seems to be some data inconsistency: - User Id in the Flagged_item and the activity table is different, so that assert should fail no?
- Same object_id for 2 activity entries, but the question_id are different - note that 1 question is flagged, and 1 answer is also flagged (to the same question). Is this an edge case I'm running into?

Problem applying Migrations 24 and 25

arghhh
Trying to migrate from 0.6.17 to 0.6.48 - Straight environment - mysql backend

UPDATE: I have updated to the latest version, and migration 24 now works. However, 25 still fails.
I've decided to delve more deeply in this, and here is my findings:

There are some issues in the migration itself:

xxx> python manage.py migrate askbot
 Running migrations for askbot:
  - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
  > askbot:0025_transfer_flagged_items_to_activity
 - Migration 'askbot:0025_transfer_flagged_items_to_activity' is marked for no-dry-run.
  ! Error found during real run of migration! Aborting.
...
    File "...askbot/migrations/0025_transfer_flagged_items_to_activity.py", line 35, in forwards
      assert(activity.content_type==flag.content_type)
    File "...django/db/models/fields/related.py", line 244, in __get__
      raise self.field.rel.to.DoesNotExist

Issue 1:

Line 35: assert(activity.content_type==flag.content_type)

The tables activity and flagged_item don't have content_type field. They have "content_type_id" fields. Same with user vs. user_id, but that one doesn't complain.

Issue 2:
Once that was fixed, I ran into the assertion failure where content type is different!

Here is the entire flagged_item table:

mysql> select * from flagged_item;
+-----------+---------------------+----+-----------------+---------+
| object_id | flagged_at          | id | content_type_id | user_id |
|       166 | 2010-11-01 15:55:02 | 1  |              21 |      10 |
+-----------+---------------------+----+-----------------+---------+

mysql> select * from activity where object_id=166;
| is_audited | object_id | user_id | content_type_id | active_at     | id  | activity_type | question_id |
+--------------------------------------------------------------------------------------------------------+
|          0 |       166 |       3 |              26 | 2010-10-28 12:| 432 |             2 |         155 |
|          0 |       166 |       3 |              21 | 2010-10-28 16:| 458 |             1 |         166 |
+--------------------------------------------------------------------------------------------------------+

There seems to be some data inconsistency: - User Id in the Flagged_item and the activity table is different, so that assert should fail no?
- Same object_id for 2 activity entries, but the question_id are different - note that 1 question is flagged, and 1 answer is also flagged (to the same question). Is this an edge case I'm running into?

Problem applying Migrations 24 and 25

arghhh
Trying to migrate from 0.6.17 to 0.6.48 - Straight environment - mysql backend

UPDATE: I have updated to the latest version, and migration 24 now works. However, 25 still fails.
I've decided to delve more deeply in this, and here is my findings:

There are some issues in the migration itself:

xxx> python manage.py migrate askbot
 Running migrations for askbot:
  - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
  > askbot:0025_transfer_flagged_items_to_activity
 - Migration 'askbot:0025_transfer_flagged_items_to_activity' is marked for no-dry-run.
  ! Error found during real run of migration! Aborting.
...
    File "...askbot/migrations/0025_transfer_flagged_items_to_activity.py", line 35, in forwards
      assert(activity.content_type==flag.content_type)
    File "...django/db/models/fields/related.py", line 244, in __get__
      raise self.field.rel.to.DoesNotExist

Issue 1:

Line 35: assert(activity.content_type==flag.content_type)

The tables activity and flagged_item don't have content_type field. They have "content_type_id" fields. Same with user vs. user_id, but that one doesn't complain.

Issue 2:
Once that was fixed, I ran into the assertion failure where content type is different!

Here is the entire flagged_item table:

mysql> select * from flagged_item;
+-----------+---------------------+----+-----------------+---------+
| object_id | flagged_at          | id | content_type_id | user_id |
|       166 | 2010-11-01 15:55:02 | 1  |              21 |      10 |
+-----------+---------------------+----+-----------------+---------+

mysql> select * from activity where object_id=166;
| is_audited | object_id | user_id | content_type_id | active_at     | id  | activity_type | question_id |
+--------------------------------------------------------------------------------------------------------+
|          0 |       166 |       3 |              26 | 2010-10-28 12:| 432 |             2 |         155 |
|          0 |       166 |       3 |              21 | 2010-10-28 16:| 458 |             1 |         166 |
+--------------------------------------------------------------------------------------------------------+

There seems to be some data inconsistency: - User Id in the Flagged_item and the activity table is different, so that assert should fail no?
- Same object_id for 2 activity entries, but the question_id are different - note that 1 question is flagged, and 1 answer is also flagged (to the same question). Is this an edge case I'm running into?

Problem applying Migrations 24 and 25

arghhh
Trying to migrate from 0.6.17 to 0.6.48 - Straight environment - mysql backend

UPDATE: I have updated to the latest version, and migration 24 now works. However, works. however, 25 still fails.
I've decided to delve more deeply in this, and here is my findings:

There are some issues in updated the trace bellow with the migration itself:exception

Got the following errors:

xxx> python manage.py migrate askbot
 Running migrations for askbot:
  - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
   > askbot:0022_init_postgresql_full_text_search
    - Migration 'askbot:0022_init_postgresql_full_text_search' is marked for no-dry-run.
   > askbot:0023_auto__add_activityauditstatus
   > askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity
    - Migration 'askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity' is marked for no-dry-run.
  > askbot:0025_transfer_flagged_items_to_activity
 - Migration 'askbot:0025_transfer_flagged_items_to_activity' is marked for no-dry-run.
  ! Error found during real run of migration! Aborting.

  ! Since you have a database that does not support running
  ! schema-altering statements in transactions, we have had 
  ! to leave it in an interim state between migrations.

  ! You *might* be able to recover with:   (migration cannot be dry-run; cannot discover commands)
  ! The South developers regret this has happened, and would
  ! like to gently persuade you to consider a slightly
  ! easier-to-deal-with DBMS.
 ! NOTE: The error which caused the migration to fail is further up.
 The following content types are stale and need to be deleted:
    askbot | badge
    askbot | flaggeditem

    Any objects related to these content types by a foreign key will also
    be deleted. Are you sure you want to delete these content types?
    If you're unsure, answer 'no'.

    Type 'yes' to continue, or 'no' to cancel: yes
    Traceback (most recent call last):
      File "manage.py", line 11, in 
          execute_manager(settings)
    File "/usr/local/lib/python2.6/site-packages/django/core/management/__init__.py", line 362, in execute_manager
...
    File "...askbot/migrations/0025_transfer_flagged_items_to_activity.py", line 35, in forwards
      assert(activity.content_type==flag.content_type)
    File "...django/db/models/fields/related.py", line 244, in __get__
      raise self.field.rel.to.DoesNotExist
 

Issue 1:

Line 35: assert(activity.content_type==flag.content_type)

The tables activity and flagged_item don't have content_type field. They have "content_type_id" fields. Same with user vs. user_id, but that one doesn't complain.

Issue 2:
Once that was fixed, I ran into the assertion failure where content type is different!

Here is the entire flagged_item table:

mysql> select * from flagged_item;
+-----------+---------------------+----+-----------------+---------+
| object_id | flagged_at          | id | content_type_id | user_id |
|       166 | 2010-11-01 15:55:02 | 1  |              21 |      10 |
+-----------+---------------------+----+-----------------+---------+

mysql> select * from activity where object_id=166;
| is_audited | object_id | user_id | content_type_id | active_at     | id  | activity_type | question_id |
+--------------------------------------------------------------------------------------------------------+
|          0 |       166 |       3 |              26 | 2010-10-28 12:| 432 |             2 |         155 |
|          0 |       166 |       3 |              21 | 2010-10-28 16:| 458 |             1 |         166 |
+--------------------------------------------------------------------------------------------------------+

There seems to be some data inconsistency: - User Id in the Flagged_item and the activity table is different, so that assert should fail no?
- Same object_id for 2 activity entries, but the question_id are different - note that 1 question is flagged, and 1 answer is also flagged (to the same question). Is this an edge case I'm running into?

Problem applying Migrations 24 and 25

arghhh
Trying to migrate from 0.6.17 to 0.6.48 - Straight environment - mysql backend

UPDATE: I have updated to the latest version, and but unfortunately, things are not progressing...seems worst: On migration 24 now works. however, 25 still fails. I've updated the trace bellow with the migration exception23:

Got the following errors:

xxx> python manage.py migrate askbot
 Running migrations for askbot:
  - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
   > askbot:0022_init_postgresql_full_text_search
    - Migration 'askbot:0022_init_postgresql_full_text_search' is marked for no-dry-run.
   > askbot:0023_auto__add_activityauditstatus
   > askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity
    - Migration 'askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity' is marked for no-dry-run.
  > askbot:0025_transfer_flagged_items_to_activity
 - Migration 'askbot:0025_transfer_flagged_items_to_activity' is marked for no-dry-run.
  ! Error found during real run of migration! Aborting.

  ! Since you have a database that does not support running
  ! schema-altering statements in transactions, we have had 
  ! to leave it in an interim state between migrations.

 ! You *might* be able to recover with:   (migration cannot be dry-run; cannot discover commands)
 = ALTER TABLE `activity` DROP COLUMN `question` CASCADE; []
   = DROP TABLE `askbot_activityauditstatus` CASCADE; []

 ! The South developers regret this has happened, and would
  ! like to gently persuade you to consider a slightly
  ! easier-to-deal-with DBMS.
 ! NOTE: The error which caused the migration to fail is further up.
 The following content types are stale and need to be deleted:
     askbot | badge
    askbot | flaggeditem

 Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

    Type 'yes' to continue, or 'no' to cancel: 

The (interesting) exceptions are:

  0023_auto__add_....py line 16
    { 'user', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['auth.User'])),
   ...
   MySQL_python-1.2.3...connection.py, line36
   _mysql_exceptions.OperationalError: (1050, "Table 'askbot_activityauditstatus' already exists")

NOTE:
I created a new database based on the original - I even drop & restore it between attempts to make sure there are no stray tables.

ORIGINAL: Got the following errors:

xxx> python manage.py migrate askbot
 Running migrations for askbot:
  - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
   > askbot:0022_init_postgresql_full_text_search
    - Migration 'askbot:0022_init_postgresql_full_text_search' is marked for no-dry-run.
   > askbot:0023_auto__add_activityauditstatus
   > askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity
    - Migration 'askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity' is marked for no-dry-run.
     Migration is now complete, but there were some errors:
       'API' object has no attribute 'get_question_from_generic_relation'
       problematic activity objects are: 339,609
       This is most likely not a big issue, but if you save this error message
       and email to admin@askbot.org, that would help. Thanks.
   > askbot:0025_transfer_flagged_items_to_activity
 - Migration 'askbot:0025_transfer_flagged_items_to_activity' is marked for no-dry-run.
  ! Error found during real run of migration! Aborting.

  ! Since you have a database that does not support running
  ! schema-altering statements in transactions, we have had 
  ! to leave it in an interim state between migrations.

  ! You *might* be able to recover with:   (migration cannot be dry-run; cannot discover commands)
  ! The South developers regret this has happened, and would
  ! like to gently persuade you to consider a slightly
  ! easier-to-deal-with DBMS.
 ! NOTE: The error which caused the migration to fail is further up.
 The following content types are stale and need to be deleted:
    askbot | badge
    askbot | flaggeditem

    Any objects related to these content types by a foreign key will also
    be deleted. Are you sure you want to delete these content types?
    If you're unsure, answer 'no'.

    Type 'yes' to continue, or 'no' to cancel: yes
    Traceback (most recent call last):
      File "manage.py", line 11, in 
          execute_manager(settings)
    File "/usr/local/lib/python2.6/site-packages/django/core/management/__init__.py", line 362, in execute_manager
...
    File "...askbot/migrations/0025_transfer_flagged_items_to_activity.py", line 35, in forwards
      assert(activity.content_type==flag.content_type)
    File "...django/db/models/fields/related.py", line 244, in __get__
      raise self.field.rel.to.DoesNotExist

Problem applying Migrations 24 and 25

arghhh
Trying to migrate from 0.6.17 to 0.6.48 - Straight environment - mysql backend

UPDATE: I have updated to the latest version, but unfortunately, things are not progressing...seems worst: On migration 23:

Running migrations for askbot:
 - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
 > askbot:0023_auto__add_activityauditstatus
 ! Error found during real run of migration! Aborting.

 ! Since you have a database that does not support running
 ! schema-altering statements in transactions, we have had 
 ! to leave it in an interim state between migrations.

! You *might* be able to recover with:   = ALTER TABLE `activity` DROP COLUMN `question` CASCADE; []
   = DROP TABLE `askbot_activityauditstatus` CASCADE; []

 ! The South developers regret this has happened, and would
 ! like to gently persuade you to consider a slightly
 ! easier-to-deal-with DBMS.
 ! NOTE: The error which caused the migration to fail is further up.
The following content types are stale and need to be deleted:

    askbot | badge
    askbot | flaggeditem

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.

    Type 'yes' to continue, or 'no' to cancel: 

The (interesting) exceptions are:

  0023_auto__add_....py line 16
    { 'user', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['auth.User'])),
   ...
   MySQL_python-1.2.3...connection.py, line36
   _mysql_exceptions.OperationalError: (1050, "Table 'askbot_activityauditstatus' already exists")

NOTE:
I created a new database based on the original - I even drop & restore it between attempts to make sure there are no stray tables.

ORIGINAL: backend Got the following errors:

xxx> python manage.py migrate askbot
 Running migrations for askbot:
  - Migrating forwards to 0032_auto__del_field_badgedata_multiple__del_field_badgedata_description__d.
   > askbot:0022_init_postgresql_full_text_search
    - Migration 'askbot:0022_init_postgresql_full_text_search' is marked for no-dry-run.
   > askbot:0023_auto__add_activityauditstatus
   > askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity
    - Migration 'askbot:0024_add_recipients_m2m_to_activity_and_denorm_question_on_activity' is marked for no-dry-run.
     Migration is now complete, but there were some errors:
       'API' object has no attribute 'get_question_from_generic_relation'
       problematic activity objects are: 339,609
       This is most likely not a big issue, but if you save this error message
       and email to admin@askbot.org, that would help. Thanks.
   > askbot:0025_transfer_flagged_items_to_activity
 - Migration 'askbot:0025_transfer_flagged_items_to_activity' is marked for no-dry-run.
  ! Error found during real run of migration! Aborting.

  ! Since you have a database that does not support running
  ! schema-altering statements in transactions, we have had 
  ! to leave it in an interim state between migrations.

  ! You *might* be able to recover with:   (migration cannot be dry-run; cannot discover commands)
  ! The South developers regret this has happened, and would
  ! like to gently persuade you to consider a slightly
  ! easier-to-deal-with DBMS.
 ! NOTE: The error which caused the migration to fail is further up.
 The following content types are stale and need to be deleted:
    askbot | badge
    askbot | flaggeditem

    Any objects related to these content types by a foreign key will also
    be deleted. Are you sure you want to delete these content types?
    If you're unsure, answer 'no'.

    Type 'yes' to continue, or 'no' to cancel: yes
    Traceback (most recent call last):
      File "manage.py", line 11, in 
          execute_manager(settings)
    File "/usr/local/lib/python2.6/site-packages/django/core/management/__init__.py", line 362, in execute_manager
...
        utility.execute()
  File "/usr/local/lib/python2.6/site-packages/django/core/management/__init__.py", line 303, in execute
      self.fetch_command(subcommand).run_from_argv(self.argv)
     File "/usr/local/lib/python2.6/site-packages/django/core/management/base.py", line 195, in run_from_argv
    self.execute(*args, **options.__dict__)
     File "/usr/local/lib/python2.6/site-packages/django/core/management/base.py", line 222, in execute
         output = self.handle(*args, **options)
    File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/management/commands/migrate.py", line 105, in handle
        ignore_ghosts = ignore_ghosts,
  File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/migration/__init__.py", line 191, in migrate_app
     success = migrator.migrate_many(target, workplan, database)
     File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/migration/migrators.py", line 221, in migrate_many
   result = migrator.__class__.migrate_many(migrator, target, migrations, database)
    File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/migration/migrators.py", line 292, in migrate_many
        result = self.migrate(migration, database)
  File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/migration/migrators.py", line 125, in migrate
      result = self.run(migration)
  File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/migration/migrators.py", line 99, in run
     return self.run_migration(migration)
  File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/migration/migrators.py", line 81, in run_migration
   migration_function()
    File "/usr/local/lib/python2.6/site-packages/South-0.7.2-py2.6.egg/south/migration/migrators.py", line 57, in 
      return (lambda: direction(orm))
   File "/usr/local/lib/python2.6/site-packages/askbot-0.6.48-py2.6.egg/askbot/migrations/0025_transfer_flagged_items_to_activity.py", line 35, in forwards
      assert(activity.content_type==flag.content_type)
 File "/usr/local/lib/python2.6/site-packages/django/db/models/fields/related.py", line 244, in __get__
                                                      raise self.field.rel.to.DoesNotExist
                                                      django.contrib.contenttypes.models.DoesNotExist