Revision model rename breaks Page revision foreign key on SQLite

Issue Summary

#8441 renamed the PageRevision model to Revision, which included a migration with a RenameModel step.

On my local machine, running against SQLite in the default configuration, this renamed the table but didn’t update the foreign key from the Page model. Looking at the SQL for the migration starts with:

% ./manage.py sqlmigrate wagtailcore 0070
BEGIN;
--
-- Rename model PageRevision to Revision
--
ALTER TABLE "wagtailcore_pagerevision" RENAME TO "wagtailcore_revision";
...

But if I then check the live_revision_id foreign key on the Page model in SQLite, it hasn’t been updated, and still points to the now-renamed wagtailcore_pagerevision table.

% sqlite3 db.sqlite3 
SQLite version 3.32.3 2020-06-18 14:16:19
Enter ".help" for usage hints.
sqlite> PRAGMA foreign_key_list('wagtailcore_page');
...
3|0|wagtailcore_pagerevision|live_revision_id|id|NO ACTION|NO ACTION|NONE
...

It looks like I’m getting hit by the ALTER TABLE RENAME issue described in the SQLite docs here:

Beginning with version 3.26.0, FOREIGN KEY constraints are always converted when a table is renamed, unless the PRAGMA legacy_alter_table=ON setting is engaged.

My PRAGMAs are defined thusly (the default values, apparently, for this version of SQLite on MacOS):

sqlite> PRAGMA legacy_alter_table;
1
sqlite> PRAGMA foreign_keys;
0

I note this commit that just went into Django (the dev version for 4.1) that explicitly disables legacy_alter_table; I wonder if I am hitting some edge case that this would fix.

Wagtail seems to have only one other instance of RenameModel for the SearchPromotion model, but I don’t think we have any foreign keys pointing to that. So this might be the first time this combination has hit Wagtail.

Steps to Reproduce

1. Start a new project with wagtail start myproject
2. cd myproject
3. ./manage.py migrate
4. ./manage.py createsuperuser and create an admin user.
5. ./manage.py runserver
6. Vist http://localhost:8000/admin/pages/add/home/homepage/3/ to create a new page (you’ll be asked to log in first)
7. Fill in the title field with something like “Test”. Click “Save Draft”. You’ll get an error: “OperationalError at /admin/pages/add/home/homepage/3/, no such table: main.wagtailcore_pagerevision”

• I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

Technical details

• Mac OS version: Big Sur 11.6.5
• SQLite3 version: 3.32.3 2020-06-18 14:16:19 02c344aceaea0d177dd42e62c8541e3cab4a26c757ba33b3a31a43ccc7d4aapl
• Python version: 3.10.4
• Django version: 4.0.5, also happens on 3.2
• Wagtail version: main (1f43d8ef51e455b92e42447fdc190d5ec83ec53c)

[laymonage]

Thanks for the report!

I think it’s worth noting that the SQLite installed on the system is not always the same as the SQLite bundled in Python. In my case:

As the legacy_alter_table is 0 on my Python’s SQLite, I did not encounter the issue.

My environment:

• macOS Monterey 12.4 on MacBook Pro M1 Pro
• Python 3.10.2 installed from Python.org
• SQLite version: 3.35.5 (Python), 3.37.0 (System)
• Django version: 4.0.5
• Wagtail version: main

[gasman]

(Hopefully) fixed in #8965.