#31320: Prevent BEGIN and COMMIT in RunSQL in atomic migrations.
-------------------------------------+-------------------------------------
     Reporter:  Adam (Chainz)        |                    Owner:  nobody
  Johnson                            |
         Type:  New feature          |                   Status:  closed
    Component:  Migrations           |                  Version:  master
     Severity:  Normal               |               Resolution:  wontfix
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Simon Charette):

 > The reason I made this was when squashing migrations on a client
 project, it had some RunSQL operations in migrations that worked fine
 alone, but when the operatiosn were squashed together it broke the
 squashed migration's transactional state.

 Interesting, were these migrations marked `atomic = False` initially? It
 looks like
 
[https://github.com/django/django/blob/2bd8df243ac6fc35e58c9fe90b20c9e42519a5ac/django/core/management/commands/squashmigrations.py#L165-L170
 the current code] completely ignores this flag. I guess the command could
 at least warn about it.

 Migration squashing is definitely an area that would benefit from a bit of
 love wrt to dependency resolving and could be a good GSOC project in the
 next years if we ever apply.

 From [https://docs.djangoproject.com/en/3.0/topics/migrations/#migration-
 squashing the docs themselves]

 > To manually resolve a CircularDependencyError, break out one of the
 ForeignKeys in the circular dependency loop into a separate migration, and
 move the dependency on the other app with it. If you’re unsure, see how
 makemigrations deals with the problem when asked to create brand new
 migrations from your models. **In a future release of Django,
 squashmigrations will be updated to attempt to resolve these errors
 itself.**

 It looks like non-atomic migrations pose a similar problem where they'd
 need to be considered an optimization barrier and require the creation of
 a standalone migration.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/31320#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.90a3d8d7b2c6422a8ee990c3e718ac6e%40djangoproject.com.

Reply via email to