#31693: Add setting to control installed PostgreSQL extensions.
-------------------------------------+-------------------------------------
Reporter: Markus Bertheau | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Migrations | Version: master
Severity: Normal | Resolution:
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 Markus Bertheau):
* status: closed => new
* resolution: wontfix =>
Comment:
felixxm, I'm sorry, I may have expressed myself not as clearly as I hoped
and that maybe led to some misunderstandings:
Replying to [comment:1 felixxm]:
> ~~I'm not sure what you're proposing, TBH.~~ (EDIT: I missed the last
sentence).
>
> > Before that it was possible to disable migrations for all apps with
MIGRATION_MODULES, mapping every app to None.
>
> It's still possible.
I meant to say that even before the MIGRATE setting feature, it was
already possible with means built-in into django – MIGRATION_MODULES – to
circumvent migrations. I didn't mean to imply that the MIGRATION_MODULES
way doesn't work anymore. Just that the problem I'm describing existed
even before the MIGRATE setting.
>
> > Both don't mix, because when disabling migrations, the extension
doesn't get installed.
>
> I don't see any issue in this, it's an expected behavior. We cannot
treat `CreateExtension()` operations differently.
Right, that's why I didn't report a bug or an issue. Nowhere in the
documentation does Django suggest that this should be working. I'm not
proposing handling `CreateExtension()` differently.
Nevertheless what I described is a use-case that I feel is common but
Django doesn't cover. That's why I reported it as a cleanup/optimization,
not as a bug.
Replying to [comment:2 felixxm]:
> > Maybe extensions should be configured in settings.DATABASES and then
automatically installed by the postgresql engine.
>
> `CreateExtension()` is a normal database migration operation, we
shouldn't treat it differentially. If you don't want to (or cannot)
control creating extensions with migrations then you can create them
directly in a database.
I'm not proposing a specific solution to the problem or that
`CreateExtension()` should be treated differently. I also know that I can
do stuff manually. That's of course a bit harder when you need to find a
place to hook into Django's database creation process during test runs.
I'm pointing out: Django has two ways to create the database structure:
1. With migrations. With all the benefits that has for gradually keeping
production databases up-to-date with respect to their structure and data.
That works well with PostgreSQL database extensions documented
[https://docs.djangoproject.com/en/dev/ref/databases/#migration-operation-
for-adding-extensions here].
2. Circumventing migrations. This has mainly a speed benefit and is
commonly used in tests, where a database is created from scratch just for
the test run. Speed is important here, as evidenced by a) the Django
feature to circumvent migrations and create the final database structure
directly based on the model definitions and b) the feature where a later
test run can reuse an existing test database.
However, the second way is no longer possible when PostgreSQL database
extensions are used. Django provides no mechanism that issues the CREATE
EXTENSION command necessary to successfully create the model as described
in models.py.
I guess what I'm asking is: Does the Django team consider this a problem
worth solving in Django, or do they say "we don't want to support that
use-case, don't bother coming up with a PR".
--
Ticket URL: <https://code.djangoproject.com/ticket/31693#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.f57f6339cfc33bbbedaf810eefc1b66e%40djangoproject.com.
