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@mitel.com>, 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