thanks again anssi, stellar reply I might do this below. the tracking is the last thing to happen before rendering, so there are no more UPDATE or INSERTS and in most cases views that use tracking don't do anything but select anyway
but OTOH I'm already running rabbit and celery so I might message them over and keep the tracking in a different process entirely. I might be able to do it more efficiently there too. -cfx On Jun 14, 11:22 am, akaariai <[email protected]> wrote: > > from django.db import connection > cursor = connection.cursor() > tracking.save() > cursor.execute("SET CONSTRAINTS ALL IMMEDIATE") > cursor.execute("SET CONSTRAINTS ALL DEFERRED") > > From postgresql documentation (http://www.postgresql.org/docs/8.4/ > static/sql-set-constraints.html) > > "When SET CONSTRAINTS changes the mode of a constraint from DEFERRED > to IMMEDIATE, the new mode takes effect retroactively: any outstanding > data modifications that would have been checked at the end of the > transaction are instead checked during the execution of the SET > CONSTRAINTS command. If any such constraint is violated, the SET > CONSTRAINTS fails (and does not change the constraint mode). Thus, SET > CONSTRAINTS can be used to force checking of constraints to occur at a > specific point in a transaction." > > The risk here is that you have something else than the tracking.save() > with deferred foreign key check pending. Now, that check could fail at > the point you run SET CONSTRAINTS ALL IMMEDIATE. The risk should be > small, though. Note that I haven't tested this code... > > Anssi -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
