#30490: migrations unique_index on (app, name).
-------------------------------------+-------------------------------------
     Reporter:  Richard              |                    Owner:  nobody
  Kojedzinszky                       |
         Type:  Bug                  |                   Status:  closed
    Component:  Uncategorized        |                  Version:  master
     Severity:  Normal               |               Resolution:  wontfix
     Keywords:  migrations parallel  |             Triage Stage:
  run                                |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Hey Richard, I understand your desire to get this issue fixed but it's
 more complex than wrapping `apply_migration` and `unapply_migration` in a
 transaction.

 For example, some backends don't support performing schema alteration
 within a transaction (e.g. MySQL will silently commit the current
 transaction on such operation) and
 [https://docs.djangoproject.com/en/2.2/howto/writing-migrations/#non-
 atomic-migrations some migrations are explicitly marked as non-atomic] to
 prevent long running transactions (e.g. large back-filling data
 migrations).

 For these reasons holding a database level lock for the duration of a
 migration application is probably not a feasible option. Altering the
 `django_migrations` table is also problematic given it's not tracked by
 migrations itself which is another kind of worms.

 In your particular case I'd suggest you explore using another form of
 distributed lock (e.g. Redis) namespaced by your deploy hash to prevent
 concurrent migration but you're probably better off getting support from
 our support channels of k8s ones where other users might have already come
 up with a solution to your problem.

 For these reasons I agree with Mariusz' resolution and ask that
 [https://docs.djangoproject.com/en/2.2/internals/contributing/triaging-
 tickets/#closing-tickets you follow triaging guidelines with regards to
 wontfix tickets]. Thanks.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/30490#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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.ff7dd4dc0f92c4c04db1ff7a59199e2f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to