[Django] #26762: Can't reuse code from django.contrib.flatpages
Django
-----------------------------------+--------------------
Reporter: vzima | Owner: nobody
Type: Bug | Status: new
Component: contrib.flatpages | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------
Our application uses it's own version of `django.contrib.flatpages`. To
reduce the amount of code needed to reuse flatpages (which is a lot, but
that's another issue) we reuse as much code from flatpages as we can -
e.g. `FlatpageForm`, `render_flatpage` and so on. We don't have
`django.contrib.flatpages` in `INSTALLED_APPS` and we really don't want to
do that, since it raises a whole other set of issues. It works fine in
Django 1.8, but stops to work when we switch to Django 1.9 with error
{{{
RuntimeError: Model class django.contrib.flatpages.models.FlatPage doesn't
declare an explicit app_label and isn't in an application in
INSTALLED_APPS.
}}}
The error itself doesn't quite make sense, since we don't use `FlatPage`
model at all, it just gets loaded.
There is simple fix which allows flatpages to be at least somewhat reused
even in 1.9, that is defining the `app_label` in `FlatPage`.
{{{
#!diff
diff --git a/django/contrib/flatpages/models.py
b/django/contrib/flatpages/models.py
index 69e84f8..abb19c1 100644
--- a/django/contrib/flatpages/models.py
+++ b/django/contrib/flatpages/models.py
@@ -25,6 +25,7 @@ class FlatPage(models.Model):
sites = models.ManyToManyField(Site, verbose_name=_('sites'))
class Meta:
+ app_label = 'flatpages'
db_table = 'django_flatpage'
verbose_name = _('flat page')
verbose_name_plural = _('flat pages')
}}}
I'm aware that this is sort of hotfix, since it doesn't solve underlying
issue, but it would allow flatpages to be used as a library.
--
Ticket URL: <https://code.djangoproject.com/ticket/26762>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-----------------------------------+------------------------------------
Reporter: vzima | Owner: nobody
Type: Bug | Status: new
Component: contrib.flatpages | Version: 1.9
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
I guess it's in the same spirit as #26401 (same request for the auth app).
I guess moving the import of the `FlatPage` model to inner imports might
be the more correct solution.
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:1>
Django
-----------------------------------+------------------------------------
Type: Bug | Status: new
Component: contrib.flatpages | Version: 1.9
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by vzima):
Personally, I share the carljm's concern ticket:21719#comment:10 that the
#21719 causes too many imports to be moved inside functions, which leads
to code that is not as tidy as it should be.
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:2>
Django
-----------------------------------+------------------------------------
Type: Bug | Status: assigned
Component: contrib.flatpages | Version: 1.9
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by vzima):
* status: new => assigned
* owner: nobody => vzima
* has_patch: 0 => 1
Comment:
PR https://github.com/django/django/pull/6973
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:3>
Django
-----------------------------------+------------------------------------
Reporter: vzima | Owner: vzima
Type: Bug | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
I also share the concerns expressed in #21719. I made the changes related
to that ticket very reluctantly to avoid blocking the 1.7 release.
I would prefer to make the Flatpage model swappable.
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:4>
Django
-----------------------------------+------------------------------------
Reporter: vzima | Owner: vzima
Type: Bug | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
I proposed to close #26401 as wontfix:
https://code.djangoproject.com/ticket/26401#comment:8
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:5>
Django
-----------------------------------+------------------------------------
Reporter: vzima | Owner: vzima
Component: contrib.flatpages | Version: 1.9
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: assigned => closed
* resolution: => wontfix
Comment:
#27109 is the ticket to make the `Flatpage` model swappable.
#26401 confirmed that you can disable creation of the model with:
`MIGRATION_MODULES = {'flatpages': None}`
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:6>
Django
-----------------------------------+------------------------------------
Reporter: vzima | Owner: vzima
Type: Bug | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by vzima):
I such case, it should be noted in documentation. When I search a solution
of the above mentioned error, I should be able to find out the
`MIGRATION_MODULES` workaround.
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:7>
Django
Reporter: Vlastimil Zíma | Owner: Vlastimil
| Zíma
Type: Bug | Status: closed
Component: contrib.flatpages | Version: 1.9
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Vlastimil Zíma):
`MIGRATION_MODULES` trick doesn't work for tests in 1.9. Test database
creation runs migration with `run_syncdb=True` which suppresses the effect
of `MIGRATION_MODULES` override. That results either in conflicts with my
own migrations or it creates database different from the one on
production.
I found no way to suppress the `syncdb` in test database creation.
--
Ticket URL: <https://code.djangoproject.com/ticket/26762#comment:8>