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 askbotRunning 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 | flaggeditemAny 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