#34332: Migrations for fields with model-referencing defaults break later
-------------------------------------+-------------------------------------
Reporter: Kenny Loveall | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 3.2
(models, ORM) |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => needsinfo
Comment:
Replying to [ticket:34332 Kenny Loveall]:
> **Use case/Goal:** I want to generate short (4-8 character), unique
codes for orders on a website (think confirmation numbers of airlines, car
license plates or the like). With sufficient length, I could just UUIDs
and be reasonably guaranteed that I won't see a collision in my lifetime,
with the smaller dataspace to pick from, this becomes no longer true.
Therefore, I generate a new random one, check to see if it's already in
use, and if so, try another one until I find one that works (and log a
warning on a first collision and error out if I try too many).
Have you tried to do this in a separate migration files (as described in
[https://docs.djangoproject.com/en/dev/howto/writing-migrations
/#migrations-that-add-unique-fields docs] for adding unique fields)?
> **What happens:** After adding a new field in the future to Order, I get
an exception when attempting to apply this migration because the migration
engine calls the default callable in the migration to get the default to
set on the rows even though I have guaranteed in the row above that there
are no rows that will need that default.
I cannot reproduce an error when running separate migration files. What
kind of exception do you encounter?
> **What I expect to happen:** Only try to call the default function if
there's a need for the default value (or even the ''potential'' for a
need). In this case, the default was already set on the model so we know
for sure there's no rows that will need a default filled in.
Django cannot know and evaluate manual operations as `RunPython` or
`RunSQL`.
--
Ticket URL: <https://code.djangoproject.com/ticket/34332#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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070186492c9274-fed38b24-c0e6-4ea2-ae17-785b32b467a7-000000%40eu-central-1.amazonses.com.
