Alban Hertroys wrote: > IIRC you had an initially deferred foreign key constraint? Do you > absolutely need that to be initially deferred, or deferrable even? > Because that's what's causing your problem, not the foreign key > constraint itself. Ok. That's from the automagickally-generated SQL from Django. I suppose they felt it was easier to set up the FK initially deferred. > If that FK does need to be initially deferred, as a workaround you can > temporarily disable the foreign key while doing your updates. Easiest is > to drop the constraint, do your updates and recreate the constraint, at > which point the database will verify that the related records match the > constraint. Of course this opens a risk where a record gets inserted > that doesn't match your FK constraint which will cause recreation to > error out and your transaction to rollback. Understood. I'll see what I can do. This migration is fully automated so it has to, via code, detect the existing constraints, remove them and reapply them during migration, if I go that route. I can't manually migrate a few thousand installs in the field. I'll follow-up if I find a good solution. Thanks, Mike -- Michael P. Soulier <michael_soulier@xxxxxxxxx>, 613-592-2122 x2522 "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein
Attachment:
signature.asc
Description: OpenPGP digital signature
