You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8f264e8
Browse filesBrowse the repository at this point in the historyBrowse files
transform() now works for tables referenced by views
Bracket the ALTER TABLE ... RENAME TO statements emitted by
transform_sql() with PRAGMA legacy_alter_table=ON/OFF. Since SQLite
3.25 the rename would otherwise rewrite references in every view
definition, which failed with "no such table" when a view referenced
the just-dropped table, and with keep_table= silently repointed
dependent views at the frozen backup table.
View definitions are now left byte-for-byte unchanged by a transform.
Closes#831
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/changelog.rst
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,13 @@
4
4
Changelog
5
5
===========
6
6
7
+
.. _unreleased:
8
+
9
+
Unreleased
10
+
----------
11
+
12
+
- ``table.transform()`` now works for tables that are referenced by views. Previously the ``ALTER TABLE ... RENAME TO`` step raised ``no such table`` if a view referenced the table being transformed. View definitions are left unchanged - see :ref:`python_api_transform_views`. This also fixes a bug where ``transform(keep_table=...)`` silently rewrote dependent views to point at the frozen backup table instead of the live one. (:issue:`831`)
13
+
7
14
.. _v3_39_1:
8
15
9
16
3.39.1 (2026-07-25)
@@ -18,6 +25,7 @@
18
25
19
26
- ``table.transform()`` now raises a ``TransactionError`` if called while a transaction is open with ``PRAGMA foreign_keys`` enabled and the table is referenced by foreign keys with destructive ``ON DELETE`` actions - ``CASCADE``, ``SET NULL`` or ``SET DEFAULT``. The pragma cannot be changed inside a transaction, so previously dropping the old table as part of the transform could fire those actions and silently delete or modify referencing rows. See :ref:`python_api_transform_foreign_keys_transactions` for details and workarounds. (:issue:`794`)
20
27
- The :ref:`CLI <cli>` and :ref:`Python API <python_api>` documentation now cross-reference each other: CLI sections link to the equivalent Python API functionality and Python API sections link back to the corresponding CLI command. (:issue:`791`)
Copy file name to clipboardExpand all lines: docs/python-api.rst
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1986,6 +1986,17 @@ A bare column name drops any foreign key that column participates in, including
1986
1986
1987
1987
Renaming a column with``rename=`` updates any foreign keys that use it, and dropping a column with``drop=`` also drops any foreign keys it participates in-for a compound foreign key this removes the whole constraint.
1988
1988
1989
+
.. _python_api_transform_views:
1990
+
1991
+
Tables referenced by views
1992
+
--------------------------
1993
+
1994
+
Tables that are referenced by views can be safely transformed - the view definitions are left byte-for-byte unchanged, and views continue to read from the live table even when ``keep_table=``is used to keep a copy of the original around.
1995
+
1996
+
A view that references a column which the transform renamed or dropped will remain defined but will raise a ``no such column`` error when it isnext queried. This is inherent to SQLite views, whose SQLis stored as text -if you rename or drop columns that a view depends on you should update that view definition yourself.
1997
+
1998
+
To achieve this, the SQL produced by ``transform_sql()`` brackets its ``ALTERTABLE...RENAMETO`` statements with``PRAGMAlegacy_alter_table=ON``and``PRAGMAlegacy_alter_table=OFF``- without this, SQLite would attempt to rewrite references to the renamed table in every view definition, which fails when a view references the table that was just dropped. One consequence is that ``PRAGMA legacy_alter_table``is reset to ``OFF`` (the SQLite default) after a transform, even if it was previously set to ``ON``for the connection.
0 commit comments