Bug: MySQL/MariaDB error with typeclasses tag migration 0007

[vincent-lg]

Brief summary of issue / Description of requested feature:

Since the new migration, 'evennia migrate' hangs. See traceback below.

  Applying typeclasses.0007_tag_migrations_may_be_slow...Traceback (most recent call last):
  File "c:\users\vincent\pyenv\Scripts\evennia_launcher.py", line 6, in <module>
    exec(compile(open(__file__).read(), __file__, 'exec'))
  File "C:\Users\Vincent\evennia\bin\windows\evennia_launcher.py", line 16, in <module>
    main()
  File "c:\users\vincent\evennia\evennia\server\evennia_launcher.py", line 1360, in main
    django.core.management.call_command(*args, **kwargs)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\core\management\__init__.py", line 119, in call_command
    return command.execute(*args, **defaults)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\core\management\base.py", line 399, in execute
    output = self.handle(*args, **options)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\core\management\commands\migrate.py", line 200, in handle
    executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\migrations\executor.py", line 92, in migrate
    self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\migrations\executor.py", line 121, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\migrations\executor.py", line 198, in apply_migration
    state = migration.apply(state, schema_editor)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\migrations\migration.py", line 123, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\migrations\operations\models.py", line 359, in database_forwards
    getattr(new_model._meta, self.option_name, set()),
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\backends\base\schema.py", line 318, in alter_unique_together
    self._delete_composed_index(model, fields, {'unique': True}, self.sql_delete_unique)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\backends\mysql\schema.py", line 87, in _delete_composed_index
    return super(DatabaseSchemaEditor, self)._delete_composed_index(model, fields, *args)
  File "c:\users\vincent\pyenv\Lib\site-packages\django\db\backends\base\schema.py", line 347, in _delete_composed_index
    ", ".join(columns),
ValueError: Found wrong number (0) of constraints for typeclasses_tag(db_key, db_category, db_tagtype)

Steps to reproduce the issue / Reasons for adding feature:

I am using MySQL to host the evennia database. Everything worked until I pulled and installed a new, clean database.

1. I git pull-ed the Evennia repository.
2. I drop my old MySQL database after dumping it, and created a new one.
3. I deleted the auto-generated file in evennia typeclasses/migrations/008...
4. Back in my MYD directory, I 'evennia makemigrations'
5. And 'evennia migrate' which gave me the traceback.

[Griatch]

evennia makemigrations should not be used except on one's own models. The MySQL wiki page was updated. Will have to test with mysql to see if I can reproduce.

[vincent-lg]

That's what I learned on the wiki, I should use 'evennia migrate' directly. However this still failed with an empty (and clean) database. The error was the same. In the log of the IRC channel is a URL to a StackOverflow question/answer on the same topic, it seems, although I was unable to find a solution. Quick fix: for the time being, I ran 'evennia migrate' (that failed) and, after that, 'evennia migrate --fake' to "pass" the 7th migration without error. This temporarily solves the issue, although I guess my tables aren't up-to-date and errors will arise sooner or later.

…

On 1/30/2017 11:13 PM, Griatch wrote: |evennia makemigrations| should not be used except on one's own models. The MySQL wiki page was updated. Will have to test with mysql to see if I can reproduce. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB_doqr3we_xQqwRTPBh1mItF1lqpbAaks5rXt8DgaJpZM4LyQmk>.

[vincent-lg]

I am not sure this is related, but a similar error is shown on a Stack overflow post. If I'm following well, the constraint that is sought doesn't match the one that was created. Perhaps quick editing in the migration file would allow to fix it. I'll check.

[vincent-lg]

I still don't get the error. Someone with a better understanding of Django migrations might though. Here's what I've gathered. After migration 6, the table typeclasses_tag looks like this:

Table	Create Table
typeclasses_tag
CREATE TABLE `typeclasses_tag` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `db_key` varchar(255) DEFAULT NULL,
  `db_category` varchar(64) DEFAULT NULL,
  `db_data` longtext,
  `db_model` varchar(32) DEFAULT NULL,
  `db_tagtype` varchar(16) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `typeclasses_tag_db_key_31dd2997_uniq` (`db_key`,`db_category`,`db_tagtype`),
  KEY `typeclasses_tag_db_key_31dd2997_idx` (`db_key`,`db_category`,`db_tagtype`),
  KEY `typeclasses_tag_f765d495` (`db_key`),
  KEY `typeclasses_tag_65fe7e54` (`db_category`),
  KEY `typeclasses_tag_36df3c33` (`db_model`),
  KEY `typeclasses_tag_cd1c31bb` (`db_tagtype`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

The constraint that causes the error contains only three fields (db_key, db_category and db_tagtype). It looks like it could be ``typeclasses_tag_db_key_31dd2997_uniqortypeclasses_tag_db_key_31dd2997_idx`. In both cases, it seems the order of fields is correct. On the other hand, I haven't been able to locate in the 007 migration, the line that modifies these constraints (the traceback isn't detailing this issue at all).

I hope this helps in debugging the error. I have a working MySQL server (MariaDB on Windows), don't hesitate if there's something to test.

[Griatch]

I just ran this on mysql from a fresh install and didn't get any traceback at migration. I take it you are testing it with a pre-populated database?

[vincent-lg]

No, it was a newly-created database as described on the wiki. I followed the instructions step by step. But I'm running MariaDB on Windows, it might make a difference.

[Griatch]

As far as I can tell at this time, this appears to be a MariaDB error, not a MySQL error. I get errors (not this one though) with MariaDB while it works with MySQL. Maybe someone else can try.

[depwl9992]

Received the same errors when trying to migrate, as @Griatch put it, a pre-populated database into MySQL (God and tutorial_world were both created, which looks to be a decent amount of data).

1. Deleted everything in the top-level directory since it's a new world, and I have nothing to lose...
2. Restarted from the beginning of Getting Started
3. Pulled commit 6db118a
4. Dropped all tables in the MySQL db.
5. Before the initial 'evennia migrate', I edited settings.py to MySQL, matching the structure of settings-default.py with db values baked in rather than loaded from the separate ini-format file that MySQL Setup recommends.
   
   Probably better mentioned in a different issue, but a note to pip install MySQL-python would be helpful in the MySQL Setup wiki page...

At this point, I ran the initial migrate and everything completed without incident. Server initialized and started correctly and the God character has been properly created. I can log in and install tutorial_world, and start playing around with it. Also can confirm that data is being generated correctly in MySQL.

[Griatch]

@depwl9992 Good to hear it works for you, this appears to be a MariaDB error rather than a MySQL error. Oh, and I added a note about the need for a Python bridge to the mysql doc thanks. :)

[depwl9992]

@Griatch Alright. I just figured I'd throw in my 2 cents, since I was getting the same behavior with MySQL as well. But what you're saying is the symptoms were maybe caused by a slightly different thing then? Actually, come to think of it, I'm not even sure what Maria is. Does this run in tandem with MySQL, or as an alternative?