Weblate: Problem with migrations

Created on 25 May 2016  路  12Comments  路  Source: WeblateOrg/weblate

Steps to reproduce

  1. Updated to tagged weblate-2,6 version from 2.4
  2. Run mirgraitons

    Actual behaviour

$ python manage.py migrate
Traceback (most recent call last):
  File "manage.py", line 31, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 345, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 348, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 399, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", line 89, in handle
    executor = MigrationExecutor(connection, self.migration_progress_callback)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 20, in __init__
    self.loader = MigrationLoader(self.connection)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 49, in __init__
    self.build_graph()
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 306, in build_graph
    _reraise_missing_dependency(migration, parent, e)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 276, in _reraise_missing_dependency
    raise exc
django.db.migrations.exceptions.NodeNotFoundError: Migration accounts.0016_add-api-keys dependencies reference nonexistent parent node (u'authtoken', u'0001_initial')

Server configuration

 Weblate weblate-2.6
 * Python 2.7.6
 * Django 1.9.6
 * six 1.10.0
 * python-social-auth 0.2.19
 * Translate Toolkit 2.0.0b2
 * Whoosh 2.7.4
 * Git 1.9.1
 * Pillow (PIL) 1.1.7
 * dateutil 2.5.3
 * lxml 3.6.0
 * django-crispy-forms 1.6.0
 * compressor 1.6
 * djangorestframework 3.3.3
 * pytz 2016.4
 * pyuca N/A
 * pyLibravatar N/A
 * Mercurial 2.8.2
 * Database backends: django.db.backends.mysql
question

All 12 comments

Please update your settings to match 2.6 ones (there are new apps used).

I thought I did... :-) thanks for the pointer!

Hey @nijel
Thanks for your quick reply.
I synced the settings file, you were totally right. I missed to add the rest_framework totally.

But now I am running into another issue:

python manage.py migrate
Operations to perform:
  Apply all migrations: trans
Running migrations:
  Rendering model states... DONE
  Applying trans.0059_auto_20160303_0934...Traceback (most recent call last):
  File "manage.py", line 31, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 345, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 348, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 399, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", line 200, in handle
    executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 92, in migrate
    self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/usr/local/lib/python2.7/dist-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 "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 198, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/migration.py", line 120, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/operations/special.py", line 183, in database_forwards
    self.code(from_state.apps, schema_editor)
  File "/opt/weblate/weblate/trans/migrations/0059_auto_20160303_0934.py", line 22, in fill_in_subscriptions
    group = Group.objects.get(name=project.name)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/manager.py", line 122, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 387, in get
    self.model._meta.object_name
__fake__.DoesNotExist: Group matching query does not exist.

Installed Versions:

 * Weblate weblate-2.6
 * Python 2.7.6
 * Django 1.9.6
 * six 1.10.0
 * python-social-auth 0.2.19
 * Translate Toolkit 2.0.0b2
 * Whoosh 2.7.4
 * Git 1.9.1
 * Pillow (PIL) 1.1.7
 * dateutil 2.5.3
 * lxml 3.6.0
 * django-crispy-forms 1.6.0
 * compressor 1.6
 * djangorestframework 3.3.3
 * pytz 2016.4
 * pyuca N/A
 * pyLibravatar N/A
 * Mercurial 3.8.2
 * Database backends: django.db.backends.mysql

Can you help? Thanks in advance...

I dont think it is a bug for everyone.

I may have screwed something. Just looking for help.

Maybe related to #1082 ?

Okay, it all went fine in the end!
The new version is awsome. So much improvement. thanks for your work @nijel

What did help you to fix it?

I setup a new instance of weblate, an compared the database schemas by hand and withhelp of Toad. It was mostly due the mistake, I mad ein 2015 when I created a merged migration.

This lead to different key names, also I did't knew migration are one way in django.
So I had been migrating between the versions, until it stopped doing anything :-)

I think my data (ACL stuff) is still a bit corrupt since I didn't reflect any changes on the data, only the schema. However it works fine, at least it seams so.

If you have an idea, how to check for data integrity, I would be very thankful.

It is small setup running with LDAP and Ldap groups, maybe it was only related to direct User based ACL which was introduced after v2.3.

Thanks for your help!

The Django migrations are usually two way unless it's python code (where I usually do not implement reverse path).

If the permissions are not correct, you can run ./manage.py setupgroups to get desired setup. It will change default groups (Users, Owners and Managers).

Yeah, basically my setup lacks any static data, introduced after 2.3 I think.

Thanks for that point, I thought it was only groups, if it does more the name is misleading,
maybe renaming it to setupfixtures would make this fact more clear?

EDIT: Fixed Typo same => name

There are also language definitions, but unless you use some rarely used languages you're fine with old data (or just run ./manage.py setuplang). But that should be all.

Awesome, thanks for everything, 2.6 runs without any errors since two days.

I got no feedback yet from the users, which is mostly a good sign ;-)

Was this page helpful?
0 / 5 - 0 ratings