Changes between Initial Version and Version 1 of Ticket #37416, comment 1
- Timestamp:
- Oct 11, 2026, 3:54:25 AM (3 hours ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #37416, comment 1
initial v1 4 4 - Adding a `flush_deferred_sql` method to the schema editor that executes and clears the pending deferred sql. It would be called inside the schema editor wherever that happens today to preserve backwards compatibility. `apply_migration` when call `flush_deferred_sql()` then `record_migration()` inside the `schema_editor` `with` block. The schema editor would still call it again, but the pending deferred sql would have been cleared and it would do nothing. 5 5 6 Does anyone have an opinion which would be preferable? 6 Does anyone have an opinion which would be preferable? 7 8 There's also currently a performance impact of recording migrations outside a transaction. I have a squashed migration that `replaces=[...]` several hundred others. `record_migration` inserts a `django_migrations` row for each of those replacements. It's taking about 0.6s to record all of them applied, because the each get their own transaction. In a single transaction, it takes about 0.01s.