[GH-ISSUE #442] upgrade from 0.9.4 or earlier to 1.0.0 fails on database migration #424

New issue

Closed

opened 2026-02-27 11:11:42 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 11:11:42 +03:00

Owner

Originally created by @tonioo on GitHub (Dec 4, 2013).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/442

Originally assigned to: @tonioo on GitHub.

Originally created by Louis-Dominique Dubeau on 2013-08-07T14:26:50Z

h1. Expected behavior

Upgrading from 0.9.4 to 1.0.0 should work without issue.

(See: https://groups.google.com/d/msg/modoboa-users/j-y7YP3RmRA/IEy0mwkeNyYJ)

h1. Actual behavior

# python manage.py syncdb --migrate
[...]
Error in migration: admin:0021_default_superadmin_ownership
DatabaseError: (1146, "Table 'modoboa.admin_user' doesn't exist")

h1. How to reproduce

Try to migrate a 0.9.4 or earlier to 1.0.0.

h1. Observations

In modoboa 1.0.0 AUTH_USER_MODEL controls how modoboa accesses the tables that hold authentication information. If set to 'admin.User', modoboa will use a model and table name which are not compatible with version prior to 1.0.0. This will be called the "new method" below.
Having AUTH_USER_MODEL set to anything else than 'admin.User' will cause the migration to fail. See: http://dev.modoboa.org/issues/436. So AUTH_USER_MODEL must be set to 'admin.User' before the migration is performed. (Ergo, commenting out AUTH_USER_MODEL is not a workaround. Yes, I've tried.)
If someone migrates from 0.9.5 to 1.0.0 there is no problem because none of the old migrations are run.
If someone migrates from any version prior to 0.9.5 to 1.0.0, the migration will fail because the OLD migrations were updated to use lib/compat.py to determine how to access the authentication information. One culprit is this migration:

admin/migrations/0021_default_superadmin_ownership.py

(There are other old migrations using lib/compat.py.)

It is introduced in 0.9.5. When run against a 0.9.4 installation, it will access the database using the new method. However, the table renaming that make the new method effective does not occur until the following migration:

admin/migrations/0029_auto__add_user__chg_field_mailbox_user__chg_field_objectaccess_user.py

So 0021_default_superadmin_ownership erroneously tries to access tables that do not exist yet.

h1. Workaround

I've copied the admin/migrations/0021_default_superadmin_ownership.py file from 0.9.5 over the one in 1.0.0. This allowed the migration to proceed. Someone migrating from an older version than 0.9.4 (which is probably inadvisable) might have to do more work.

Originally created by @tonioo on GitHub (Dec 4, 2013). Original GitHub issue: https://github.com/modoboa/modoboa/issues/442 Originally assigned to: @tonioo on GitHub. **Originally created by Louis-Dominique Dubeau on 2013-08-07T14:26:50Z** h1. Expected behavior Upgrading from 0.9.4 to 1.0.0 should work without issue. (See: https://groups.google.com/d/msg/modoboa-users/j-y7YP3RmRA/IEy0mwkeNyYJ) h1. Actual behavior <pre> # python manage.py syncdb --migrate [...] Error in migration: admin:0021_default_superadmin_ownership DatabaseError: (1146, "Table 'modoboa.admin_user' doesn't exist") </pre> h1. How to reproduce Try to migrate a 0.9.4 or earlier to 1.0.0. h1. Observations 1. In modoboa 1.0.0 AUTH_USER_MODEL controls how modoboa accesses the tables that hold authentication information. If set to 'admin.User', modoboa will use a model and table name which are not compatible with version prior to 1.0.0. This will be called the "new method" below. 2. Having AUTH_USER_MODEL set to anything else than 'admin.User' will cause the migration to fail. See: http://dev.modoboa.org/issues/436. So AUTH_USER_MODEL must be set to 'admin.User' before the migration is performed. (Ergo, commenting out AUTH_USER_MODEL is not a workaround. Yes, I've tried.) 3. If someone migrates from 0.9.5 to 1.0.0 there is no problem because none of the old migrations are run. 4. If someone migrates from any version prior to 0.9.5 to 1.0.0, the migration will fail because the OLD migrations were updated to use lib/compat.py to determine how to access the authentication information. One culprit is this migration: admin/migrations/0021_default_superadmin_ownership.py (There are other old migrations using lib/compat.py.) It is introduced in 0.9.5. When run against a 0.9.4 installation, it will access the database using the new method. However, the table renaming that make the new method effective does not occur until the following migration: admin/migrations/0029_auto__add_user__chg_field_mailbox_user__chg_field_objectaccess_user.py So 0021_default_superadmin_ownership erroneously tries to access tables that do not exist yet. h1. Workaround I've copied the admin/migrations/0021_default_superadmin_ownership.py file from 0.9.5 over the one in 1.0.0. This allowed the migration to proceed. Someone migrating from an older version than 0.9.4 (which is probably inadvisable) might have to do more work.

kerem

2026-02-27 11:11:42 +03:00

closed this issue
added the
bug

documentation
labels

kerem commented

2026-02-27 11:11:43 +03:00

Author

Owner

@tonioo commented on GitHub (Dec 4, 2013):

Posted by Antoine Nguyen on 2013-08-31T15:28:42Z

Applied in changeset commit:2b3349749bfd44e42a40518223b0aec1ce14848b.

@tonioo commented on GitHub (Dec 4, 2013): **Posted by Antoine Nguyen on 2013-08-31T15:28:42Z** Applied in changeset commit:2b3349749bfd44e42a40518223b0aec1ce14848b.