wagtail: Django "flush" management command fails because of "wagtailsearch_editorspick" table
I’m gearing up to use Wagtail for a new project and ran into a small issue flushing a Postgres database.
With a stock Wagtail installation (no contrib apps), running python manage.py flush fails because of the wagtailsearch_editorspick table:
CommandError: Database sample_project couldn't be flushed. Possible reasons:
* The database isn't running or isn't configured correctly.
* At least one of the expected database tables doesn't exist.
* The SQL was invalid.
Hint: Look at the output of 'django-admin sqlflush'. That's the SQL this command wasn't able to run.
The full error: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "wagtailsearch_editorspick" references "wagtailcore_page".
HINT: Truncate table "wagtailsearch_editorspick" at the same time, or use TRUNCATE ... CASCADE.
After doing some digging, it looks like the key is that this migration leaves the wagtailsearch_editorspick table in the database for the contrib app to pick up:
Relevant comment:
# If wagtailsearchpromotions isn't installed, this table will remain
# in the database unmanaged until it is. This could potentially happen
# at any point in the future so it's important to keep this behaviour
# even if we decide to squash these migrations.
I’m new to Wagtail (and really liking it so far!), so I’m not sure what the fix is here. If someone can point me in the right direction, though, I’m happy to put together a PR.
Thanks!
Additional background:
Installed apps:
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
# Wagtail
'wagtail.wagtailcore',
'wagtail.wagtailadmin',
'wagtail.wagtaildocs',
'wagtail.wagtailsnippets',
'wagtail.wagtailusers',
'wagtail.wagtailimages',
'wagtail.wagtailembeds',
'wagtail.wagtailsearch',
'wagtail.wagtailsites',
'wagtail.wagtailredirects',
'wagtail.wagtailforms',
'compressor',
'taggit',
'modelcluster',
# Other
'rest_framework',
)
Requirements:
# Django (1.8 is a long-term support release)
Django==1.8.5
# Third-party libraries
djangorestframework==3.2.4
Pygments==2.0.2
psycopg2==2.6.1
pysaml2==3.0.0
requests==2.7.0
wagtail==1.1
# Testing and debugging
django-debug-toolbar==1.3.2
coverage==4.0
model-mommy==1.2.5
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 19
- Comments: 29 (8 by maintainers)
Commits related to this issue
- Problem with flushing DB. https://github.com/wagtail/wagtail/issues/1824 according to that issue. — committed to TomaszKolek/datamanager by TomaszKolek 4 years ago
- Problem with flushing DB. https://github.com/wagtail/wagtail/issues/1824 according to that issue. — committed to TomaszKolek/datamanager by TomaszKolek 4 years ago
- Problem with flushing DB. https://github.com/wagtail/wagtail/issues/1824 according to that issue. — committed to TomaszKolek/datamanager by TomaszKolek 4 years ago
- Problem with flushing DB. https://github.com/wagtail/wagtail/issues/1824 according to that issue. — committed to TomaszKolek/datamanager by TomaszKolek 4 years ago
- Problem with flushing DB. https://github.com/wagtail/wagtail/issues/1824 according to that issue. — committed to TomaszKolek/datamanager by TomaszKolek 4 years ago
- Problem with flushing DB. https://github.com/wagtail/wagtail/issues/1824 according to that issue. — committed to TomaszKolek/datamanager by TomaszKolek 4 years ago
- Problem with flushing DB. https://github.com/wagtail/wagtail/issues/1824 according to that issue. — committed to TomaszKolek/datamanager by TomaszKolek 4 years ago
- settings: Add wagtail.contrib.search_promotions to allow tests to run https://github.com/wagtail/wagtail/issues/1824 — committed to open-contracting-archive/covid-19-procurement-explorer-admin by jpmckinney 3 years ago
- Revise wagtailsearch migrations to avoid keeping editorspick table around Fixes #1824, as per the outline in https://github.com/wagtail/wagtail/issues/1824#issuecomment-1271840741. Revise the existin... — committed to gasman/wagtail by gasman 2 years ago
- Revise wagtailsearch migrations to avoid keeping editorspick table around Fixes #1824, as per the outline in https://github.com/wagtail/wagtail/issues/1824#issuecomment-1271840741. Revise the existin... — committed to Yekasumah/wagtail- by gasman 2 years ago
the simplest solution for me was to add
"wagtail.contrib.search_promotions",to myINSTALLED_APPS->in addition i learned a nifty little trick while reading this issue. you are able to deliver everything before a deadline easily: just move the ticket to the next milestone. works since 1.3 reliably
We faced the same problem, but in our case it was just that our test suite started to fail when integrating wagtail into our existing django project. Here is a workaround for someone that want to use wagtail, but not include wagtailsearchpromotions. Please note that this might/will cause problems if you later on want to use wagtailsearchpromotions, as the wagtailsearch_editorspick no longer exists, and the wagtailsearchpromotions initial migration will/might fail. Note that I haven’t tried that path, but I suspect it might fail.
This migration needs to be added to your project. Please note the danger of this migration as well, in case you already have data in wagtailsearch_editorspick as it will remove related rows.
As most of you, I had this problem while integrating wagtail in a existing project. After reading this thread I found out that only my Selenium tests were failing and that was due to cascade not being specified. I simply overrode the
_fixture_teardwon()to forceallow_cascadewhen the flush command was called.I ran into the same issue where the table wagtailsearch_editorspick did not live in my database but was defined as a model. So when I ran
manage.py flush, I hit the same errorLooking at the output of
./manage.py sqlflushyou can see the SQL statement that django tries to run.(note that I have wagtail integrated with another application called css_portal).When I execute that command in the dbshell using
./manage.py dbshellI can see the problem (and the suggested fix).When I run the same command with “CASCADE;” at the end, it works.
The django flush.py management command on line 34 (of django 2.1 anyway) has built in support to allow the cascade option.
34 allow_cascade = options.get('allow_cascade', False)But it is a “stealth option” and set to False by default. You cannot currently specify something like --allow_cascade=True on the
./manage.py flushcommand line.So, using the django instructions for over-riding a management module I copied flush.py to myapp/management/commands/flush.py and inserted the following in the add_arguments() function (at line 26)
And now, I can simply run
./manage.py flush --allow_cascade=Trueand the flush works perfectly.Hope this helps someone!
Any updates on the implementation, I am having trouble running tests with fixtures?
To minimize the damage at this point, a solution might be to remove the FK constraint on the
wagtailsearch_editorspicktable in an additional migration in thewagtailsearchapp, turning the field into a simple integer field, and to restore that constraint in thewagtailsearchpromotionsmigrations.Thanks, @gasman - that worked
@GabrielBogo As @chosak mentioned, adding
"wagtail.contrib.search_promotions"to INSTALLED_APPS in your test environment should serve as a workaround.Working towards a proper solution… The migrations that brought about the current situation are:
wagtailsearch.0001_initial: creates thewagtailsearch_editorspicktablewagtailsearch.0003_remove_editors_pick: removes the EditorsPick model from the wagtailsearch application state but leaves thewagtailsearch_editorspicktable in the database as an unmanaged tablewagtailsearchpromotions.0001_initial: renames thewagtailsearch_editorspicktable towagtailsearchpromotions_searchpromotionand modifies the wagtailsearchpromotions application state to ‘adopt’ that modelAll of these migrations have been around since Wagtail 1.1, and at this point we can reasonably assume that nobody is going to upgrade directly from Wagtail 1.1 to 4.x without deploying any intermediate version (or, at least, if they’re foolhardy enough to do that, the onus is on them to devise their own migration plan), so we can dismiss the possibility of a project being in some historical state where migrations are only partially applied, or where a
wagtailsearch_editorspicktable contains meaningful data.This means that any prospective bugfix will need to handle all of these initial states:
./manage.py migratewagtail.contrib.search_promotionsin INSTALLED_APPS. These have an unmanagedwagtailsearch_editorspicktable and are affected by the bug described here.wagtail.contrib.search_promotionsin INSTALLED_APPS. These have awagtailsearchpromotions_searchpromotiontable managed by Django, and nowagtailsearch_editorspicktable. They are not affected by this bug (since the flush command knows about all tables that exist in the database).From these, we want to arrive at a state where
wagtailsearch_editorspickdoes not exist, andwagtailsearchpromotions_searchpromotionexists if and only ifwagtail.contrib.search_promotionsis in INSTALLED_APPS. Additionally:wagtail.contrib.search_promotionsto INSTALLED_APPS and running migrate must still successfully create thewagtailsearchpromotions_searchpromotiontable.My first pass at a solution would be:
wagtailsearchpromotions.0001_initialto create searchpromotion as a new table, rather than renaming editorspickwagtailsearch.0003_remove_editors_pickto do nothingwagtailsearch.0007migration to drop the editorspick table and modelHowever, this fails on scenario 3, because then the wagtailsearch.0007 migration will end up trying to delete a table that doesn’t exist. I expect there’s a way to specify “drop table if it exists” to work around that, but it feels like I’m missing a more elegant solution - if we got into this mess without any conditional logic, surely we can get out of it again?
I don’t know if this is useful information or not, but I only hit this when using LiveServerTestcase. TestCase and the WagtailTestCase don’t trigger it for me. Assuming it is related to TransactionTestCase rollback optimizations.
Thanks @peterb154. This worked for me:
I’m having this same issue whenever I try and run tests here is my output. This is making it so I can’t run any tests that work with Page models.
I really need a fix for this or we might have to stop using wagtail