#23906: "ValueError: Found wrong number (0) of constraints" when migrating
backwards with from alter_unique_together migration.
-------------------------------------+-------------------------------------
     Reporter:  liavkoren            |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Migrations           |                  Version:  1.7
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:
  alter_unique_together migrations   |  Unreviewed
  constraints valueError             |      Needs documentation:  0
    Has patch:  0                    |  Patch needs improvement:  0
  Needs tests:  0                    |                    UI/UX:  0
Easy pickings:  0                    |
-------------------------------------+-------------------------------------
Changes (by carljm):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I would guess that reproducing for purposes of writing a tests shouldn't
 be too hard with some raw SQL; it seems this is simply a matter of the
 order in which columns are listed in a constraint. The question is whether
 the suggested fix is actually correct. Does it break any existing tests?

 How does migrations currently handle it if you change the ordering of a
 `unique_together` without otherwise changing the constituent fields?

 I notice there is an `ORDER BY ordinal_position` in at least the
 PostgreSQL implementation of `get_constraints`, suggesting that the order
 of fields in a constraint is relevant.

 I think that's the basic question here: either a constraint with the same
 fields in a different order is semantically the same constraint (in which
 case your suggested fix seems right), or its semantically a different
 constraint (in which case the current behavior is correct, and you just
 have a mismatch between the state of your database and what migrations
 thinks is the state of your database, which is something you need to deal
 with locally).

 I don't actually know which of those is correct in terms of the underlying
 database semantics, though the fact that at least PG clearly tracks field
 ordering within a constraint suggests the latter.

--
Ticket URL: <https://code.djangoproject.com/ticket/23906#comment:1>
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/067.7bc18299d42b3a9f2c74328488178fa0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to