Opened 13 months ago

Last modified 7 months ago

#27141 new Cleanup/optimization

makemigrations fails with PermissionDenied on django_migrations

Reported by: Sjoerd Job Postmus Owned by: nobody
Component: Migrations Version: 1.10
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


On a project I'm currently working on, I have read-only access to 1 table on a database.

Similar to #27054, except that the table django_migrations does exist, I just don't have read-access to it.

Error message:

django.db.utils.ProgrammingError: permission denied for relation django_migrations.

The error occurs in, specifically the line

return set(tuple(x) for x in self.migration_qs.values_list("app", "name"))

Change History (7)

comment:1 Changed 13 months ago by Sjoerd Job Postmus

Pull request at

Let me know if I missed anything.

comment:2 Changed 13 months ago by Claude Paroz

Component: UncategorizedMigrations
Has patch: set
Triage Stage: UnreviewedAccepted
Type: UncategorizedCleanup/optimization

comment:3 Changed 13 months ago by Sjoerd Job Postmus

Responding to Tim Graham his remark on the pull request:

Sure, you could let us know how inspectdb currently works with this situation. I guess it might hit that exception block. I guess if that's better than silently skipping such tables then that solution may not be ideal, or at least we'd need a new parameter to introspection.table_names() to skip unowned tables.

Yes, I'm indeed hitting the exception handler there. Based on results from Django==1.9.7, it comes from get_table_description which has a SELECT * FROM %s LIMIT 1.

So I think what would make the most sense would be to add a try/except DatabaseError around the part where the applied migrations are obtained, and then (re-)raise a MigrationSchemaMissing instead. The error message is after all correct: "\nNot checking migrations as it is not possible to access/create the django_migrations table.".

comment:4 Changed 13 months ago by Tim Graham

Has patch: unset

Feel free to send a pull request to my branch or give my PR a review so we can merge it and continue this ticket in a new PR.

comment:5 Changed 13 months ago by Tim Graham

In ticket:27142#comment:3 I asked whether or not we should even keep this check in makemigrations. It's getting tedious to deal with all the edge cases, with questionable benefit in my view.

comment:6 Changed 11 months ago by ldng

A similar usecase but maybe needing a different solution (or even a different ticket) is that of a read only database connection.

Say you have :

    'default': ...,
    'another_db_rw': ...,
    'yet_another_db_r': ...,

makemigrations will try to "make" migrations for all 3 connections. Maybe a solution for that would be a '--database' option like migrate command ?

Last edited 7 months ago by Anton Samarchyan (previous) (diff)

comment:7 Changed 11 months ago by Tim Graham

You should set up database routers so that allow_migrate() returns False for read-only connections.

Note: See TracTickets for help on using tickets.
Back to Top