[Django] #27141: makemigrations fails with PermissionDenied on django_migrations
Django
-------------------------------+--------------------
Reporter: sjoerdjob | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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 `recorder.py:MigrationRecorder.applied_migrations`,
specifically the line
return set(tuple(x) for x in self.migration_qs.values_list("app",
"name"))
--
Ticket URL: <https://code.djangoproject.com/ticket/27141>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: sjoerdjob | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.10
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by sjoerdjob):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Pull request at https://github.com/django/django/pull/7172
Let me know if I missed anything.
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:1>
Django
Reporter: sjoerdjob | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* component: Uncategorized => Migrations
* has_patch: 0 => 1
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:2>
Django
Reporter: sjoerdjob | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sjoerdjob):
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.".
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:3>
Django
Reporter: sjoerdjob | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* has_patch: 1 => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:4>
Django
Reporter: sjoerdjob | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:5>
Django
Reporter: Sjoerd Job Postmus | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by ldng):
A similar usesase but maybe needing a different solution (or even a
different ticket) is that of a read only database connection.
Say you have :
{{{#!python
DATABASES = {
'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 ?
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:6>
Django
Reporter: Sjoerd Job Postmus | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
You should set up database routers so that `allow_migrate()` returns
`False` for read-only connections.
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:7>
Django
Reporter: Sjoerd Job Postmus | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Jacob Walls):
Fixed by #31504 in 9756c334294ad573d887b449e2fe1cc87387af40.
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:8>
Django
Reporter: Sjoerd Job Postmus | Owner: nobody
Component: Migrations | Version: 1.10
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Jacob Walls):
* status: new => closed
* resolution: => fixed
--
Ticket URL: <https://code.djangoproject.com/ticket/27141#comment:9>