# 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 Got the following errors:

xxx> python manage.py migrate askbot
- Migration 'askbot:0022_init_postgresql_full_text_search' 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
- 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:

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?

Type 'yes' to continue, or 'no' to cancel: yes
Traceback (most recent call last):
File "manage.py", line 11, in <module>
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 <lambda>
return (lambda: direction(orm))
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


### Problem applying Migrations 24 and 25

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

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

Running migrations for askbot:
! 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:

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?

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


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
- Migration 'askbot:0022_init_postgresql_full_text_search' 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
- 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:

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?

Type 'yes' to continue, or 'no' to cancel: yes
Traceback (most recent call last):
File "manage.py", line 11, in <module>
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 <lambda>
return (lambda: direction(orm))
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
...


### 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 and migration 23:24 now works. however, 25 still fails. I've updated the trace bellow with the migration exception

Got the following errors:

xxx> python manage.py migrate askbot
- Migration 'askbot:0022_init_postgresql_full_text_search' is marked for no-dry-run.
- 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:   = ALTER TABLE activity DROP COLUMN question CASCADE; []
= DROP TABLE askbot_activityauditstatus CASCADE; []

(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:

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?

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


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
- Migration 'askbot:0022_init_postgresql_full_text_search' 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
- 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:

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?

Type 'yes' to continue, or 'no' to cancel: yes
Traceback (most recent call last):
File "manage.py", line 11, in <module>
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, and migration 24 now works. however, works. However, 25 still fails.
I've updated the trace bellow with decided to delve more deeply in this, and here is my findings:

There are some issues in the migration exception

Got the following errors:itself:

xxx> python manage.py migrate askbot
- Migration 'askbot:0022_init_postgresql_full_text_search' is marked for no-dry-run.
- 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:

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?

Type 'yes' to continue, or 'no' to cancel: yes
Traceback (most recent call last):
File "manage.py", line 11, in <module>
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?

 5 retagged Evgeny 14295 ●56 ●103 ●216 http://askbot.org/

### 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
- 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
- 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?